Flow Documentation with Mark Ross

For this week’s episode of the Salesforce Admins Podcast, we’re joined by Mark Ross, Senior Tech Writer at Salesforce. We ask Mark how he approaches documentation and how you can make a difference for your users.

Join us as we talk about what goes on behind the release notes, what’s important when you write your own documentation and the importance of learning your variables when it comes to Flow.

You should subscribe for the full episode, but here are a few takeaways from our conversation with Mark Ross.

The Salesforce CCX Team

You might recognize Mark’s voice from the WizardCast. At Salesforce, however, he works on the CCX team (Content and Communications Experience). They help with Trailhead, documentation, and more, and Mark specifically focuses on automation services: Flow, Process Builder, Workflow and Approvals and even IoT.

“I’m someone who is a very technical-minded person, but I never learned to code—not really,” Mark says, “Flow can do all these things that, ordinarily, I would need code to do and it opened up a whole new world for me.” In other words, Mark is a certified Flownatic and he wants to share that enthusiasm with everyone and teach them how to harness the power of automation.

Mark’s keys for writing good documentation

So how do you write documentation for new features? It starts with sitting down with the engineers to actually go over everything and look at any text that might be a part of the UI. Next, Mark and his team turn to the release notes. “Believe it or not, release notes are the most-viewed documentation of Salesforce,” he says. They want to not just communicate what’s happened, but why it’s useful.

When Mark is prepping Flow Release Notes, he starts by going through the headers to see what will affect his current customers or users. Sometimes, that also means noticing new features because it gives you the ability to let people know what’s on the way.

“If you release something for your users and you don’t write down how to do it, you’re automatically doing them a disservice,” Mark says, “even if you train them face-to-face, that’s not the same as them having something they can come back to later.” Especially if you can keep things simple and use screenshots to help point people in the right direction.

There’s a lot more in this episode, including what Mark and his team think about when they write error messages, and an adorable special guest.

Links:

• Download TrailheadGO! – http://sforce.co/adminpodgo
• Flow Builder Documentation
• The WizardCast

Social:

• Mark: @MarkRoss__C
• Salesforce Admins: @SalesforceAdmns 
• Gillian: @GillianKBruce
• Mike: @MikeGerholdt

Full Show Transcript

Mike Gerholdt: Welcome to The Salesforce Admins Podcast, where we talk about product, community and career to help you become an awesome admin. This week, we’re talking with Mark Ross, who’s a technical writer, about flow documentation and how we learned about flow and it’s features. Now, you might have heard Mark on another podcast, he’s also the cohost of The Wizard Cast, which is a big fan favorite of everybody that records this podcast, so shout out there. And, he’s also given a ton of Dreamforce presentations around flow. So this is very exciting, I’m so glad we got Mark on the podcast. So here we go, let’s bring Mark on the pod.
So Mark, welcome to the podcast.

Mark Ross: Thanks, Mike. It’s good to talk to you again, it’s been a little while.

Mike Gerholdt: It has. And, for those community members that perhaps are like, “This voice sounds familiar,” you’re also on another podcast. We’ll start there as your introduction.

Mark Ross: Well, that is true. There’s a little podcast that’s out there called The Wizard Cast, and despite it’s name, we actually talk about Salesforce. We don’t have too many episodes going out lately because pandemic stress and all that. But yeah, we’re out there on all the major platforms for podcasts.

Mike Gerholdt: Now, when I think flow and Salesforce flow, and dare I say flownatics, I think of Mark Ross because I know you’ve been on stage at Dreamforce talking flow. Gillian and myself have done a lot of content around flow. Let’s start off with what you do at Salesforce and how that relates to flow.

Mark Ross: Sure. Well, I am on the Content and Communications Experience, CCX. We specifically are responsible for creating the content that is customer visible. In this case, specifically that’s going to be documentation. But we also help with Trailhead, our particular team, and a few other things that are out there, that are community facing. Not everything that’s customer community facing, but we still have quite a bit of it.
I specifically am on the CX team, as we say, for automation services. In other words, flow, process builder. Even workflow and approvals, and even IoT.

Gillian Bruce: Just a few things to cover in your scope.

Mark Ross: Just a few things.

Gillian Bruce: Not too bad, right?

Mark Ross: Right.

Gillian Bruce: So Mark, I would also love to maybe just give a tiny bit of background into how you came into this role, because you’ve been at Salesforce a couple years now, maybe?

Mark Ross: Yeah, I started in January ’19.

Gillian Bruce: Okay. And before that, we talk about flownatics, most of the context in which I think Mike and I are very familiar with you and your work is actually pre-Salesforce days, when you were not part of the company but you were an end-user, and an MVP and a leader in the community. Can you talk to us a little bit about how you became a flownatic?

Mark Ross: Back in 2010, I attended my very first Dreamforce. And, we as a company, the company I was working for at the time, we hadn’t even really started using it yet. But my company sent us all to Dreamforce to say, “Hey, you’re going to start using this Salesforce thing, you might as well go learn about it.”
And I attended a session on the desktop flow designer, and it was literally an executable you had to run on your machine that saved .flow files that you then had to upload into Salesforce, and I was absolutely entranced. As much as I had drunk the blue Kool-Aid at Dreamforce in general, my very first Dreamforce, flow to me was the big takeaway. I immediately went back to company to start figuring out all the things I could do with flow. Every new position that I took at the same company or different companies, I was always flow, flow, flow, flow, flow. Until the point where I realized, I love flow, I love flow. Why is nobody else talking about flow? This is an amazing thing, nobody in the community’s every talking about flow, so I decided I’m going to start talking about it. That’s basically how it happened. I met Brian Kwong at another Dreamforce, and he and I became fast friends and flownatic buddies. He and I basically became partners in crime.
From there on, I basically had a lot of different positions. And at some point I’m just like, “You know what? I’m done with at the very least the consulting thing, and not feeling the admin thing as much any more. I wonder if there’s something I could do for Salesforce?” I started talking to people, I started looking around, and eventually ended up at Salesforce.org, where I was writing documentation for some of their gift entry products. And then, last year the flow documentation team, the automation services CX team, reached out to me and said, “Hey, we have an opening, we hear you love flow.” I was like, “Man, I love Salesforce.org, my team here is really great, but it’s flow! I can’t say no to that,” so I made the jump. That’s the story.

Mike Gerholdt: So flow caught fire for you. Why do you think it really clicks for some people like yourself and not everyone?

Mark Ross: I think, for me specifically and I’ll branch this out into how I think other people probably feel about it just from my guess. For me, I am somebody who is a very technical-minded person, but I never really learned to code, not really. Learning Apple Basic in grade school isn’t the same thing as sitting down with Apex and whipping out a whole bunch of functions and triggers. It’s not the same thing. So I had the programmer’s mindset, but I didn’t have the experience. Every time I tried to sit down to learn it, it became a prohibitive thing. I even went to Apex training, and it just, for some reason, wasn’t clicking.
But when I sat down in front of flow, it clicked. To me, it was this is the things that I would normally need to do, especially when you go back to 2010, 2011 when I first saw this. Flow can do all these things that, ordinarily, I would need code to do, I would need Visualforce to do, and that was a big, big deal. All of a sudden, it was a whole new world without actually singing the Disney lyrics because that would get us in trouble. It was I now have more power than I know what to do with, and anybody has previously considered, without needing code. I think that was part of the big allure at first, it was this ability … I can do things workflow can’t, and I don’t need to write a line of code.
That is incredibly attractive to people, maybe they are Salesforce literate, they’ve been doing Salesforce for a long time. But code, the hurdle’s just a bit too high without hitting your toes on it. To be able to still have a good measure of that power, to be able to do things that your users want and that you want to do for your users, and to make really snappy interfaces as we’re starting get better looks for flow now, that’s incredibly alluring. That’s where I think the draw comes from.

Gillian Bruce: I mean, I think you encapsulate it. Clearly, you hear the flownatic passion in your voice. I think what you outlined is a lot of the reasons why we definitely are focusing on automation and all things flow this month for admins.
I would love to maybe hear a little bit more. Mike said that, basically, you’re in documentation land. I don’t know why I make everything a land, a feature set in this podcast. Maybe now you have me thinking Disney and I’m thinking, “Oh, we have Automation Land and Documentation Land.”

Mike Gerholdt: Land of the Lost.

Gillian Bruce: It’s all these happy places, the happiest places on Earth. Or, on the platform. Can you talk to us a little bit about how documentation plays into the arena of flow? And what the role is, how you approach it? What is your methodology there?

Mark Ross: Sure. We have a cycle, just like their developers do. They have a cycle where, any given release, they have to do things in a certain order, and we do as well. When we’re presented with the actual things that are being worked on by the engineers, we actually help to do the UI text. We don’t just do documentation, we’re actually sitting down and saying, “All right, this button should be called this because, unfortunately, the name the developers came with is a little bit misleading.” Everything from errors messages, to modals, to the actual clickable interface, if it’s got text in it, we’re looking at it. That’s part of our cycle.
The next thing we look at is release notes. Because believe it or not, release notes is actually the most viewed documentation of Salesforce. That is actually a really important area of focus for us, so we spend quite a bit of time on release notes as well, making sure that they are understandable, making sure they’re communicating things, not just what’s happened but how it’s useful as well to the users. It’s not just enough to say, “Well, we’ve made this.” What we also are trying to say, “We made this, and you can use it for this. Or, it improves your life in this way.”
Apart from release notes, we also of course do the actual documentation. So you have the help doc, also the dev doc, things like the API docs, metadata API docs, things like that. We don’t necessarily touch all the little things that are dev doc oriented, but we do help with those metadata, API focused areas. But the documentation, of course, is a big deal. A lot of that, to be honest, we’re going in and we’re updating things that need to be updated. But every now and then, we’re going to put out a new page. The thing is, the flow documentation started in a bit of a rough spot because it was relatively complicated. Many years ago, it started out relatively complicated and it was difficult to just, all of a sudden, slap down a whole bunch of documentation for that. So over time, a lot of documentation has been added. If you checked out the flow documentation five years ago, it’s a very different beast now than it was then.
We’re covering a lot more topics. We’re covering a lot of things like best practices, how [inaudible] works, limits. Some of those limits docs are my favorite docs. You wouldn’t think the documentation that says the things you can’t do would be one of my favorites, but it absolutely is. Because I can’t tell you how many times I’ve hit some kind of an error, and didn’t know what it was, and somebody pointed, “Hey did you go over your limits?” I was like, “Limits? There are limits?” Yes, there are limits so you have to go check those out. Element limits, sociable limits, things like that. So many of my problems, and so many of the people I’ve talked to, people in the community, their problems have been solved just by going to look at that. There’s all sorts of other really helpful things, more in use cases, example use cases that are out there as well. References for individual parts of flow, all the different screen components, all the different elements, they all have their own individual pages so those are valuable, too.
And then, after of course documentation, there is Trailhead. We don’t necessarily manage all of the Trailhead content, but there are certain badges that we definitely help to maintain. There are some that we’re having to retire because they’re, frankly, out of date. At some point in the future, we’re going to have some more flow content coming, and we’re definitely wanting to hear your feedback on that as well. Because we know there are some gaps in how the Trailhead badges guide people, we want things to be not too prescriptive but not unhelpful, either. So if anybody has any input on that, we’d very much welcome that.
I think that pretty much covers our doc cycle and everything we put out.

Mike Gerholdt: You hope, until the next release.

Mark Ross: Right, exactly. There’s always more, right?

Mike Gerholdt: I’m trying to bounce between being a beginning admin learning flow, and somebody that’s been on the platform for a while. You’ve been around for a while, you remember before Trailhead and only having documentation as a way to learn a product.
I’m going to use the release as a jumping off point. As somebody that’s rolled out flow, that has a lot of processes and flows built, and I’m sure a lot of listeners do as well, what are things in the release notes that you look for?

Mark Ross: When you’re talking about flow?

Mike Gerholdt: Yes.

Mark Ross: Well, my general behavior for flow release notes is the first thing I’m going to do is I’m going to do a pass, just start reading the headers. I’m looking for things that are going to … If I’m an admin, in my days as an admin, I’m looking for things that impact my current customers first. Whether I’m a partner, implementer, I’m looking for my customers. If I’m an admin for a company, I’m looking for my company, the things that are in my org or orgs right now. Because there are going to be changes, there are going to be critical updates and those things can have an impact on the things already out there. But, sometimes there’s a new feature that came out.
Just two months ago I was telling somebody in sales that I couldn’t do this. Now all of a sudden, this is now a feature that’s going to be available. It’s going to be beta, it’s going to be new, but at least I can tell them it’s on the way. That’s something you can … Especially if you’re working with a sales department, a sales enablement, or whatever department that you’re working to enable, just being able to tell them, “Yes, it’s coming. It’s on the way,” will make them feel so much better.
So reading the release notes, and getting an idea of what’s out there and what’s coming, even if you can’t use it, even if you’re tied behind procedures that … I say tied, that makes it sound negative. Even if you’re having to listen to procedures that are governance oriented saying, “Well, you can implement something until goes through this change management board,” that’s great, you always respect the change management board. But at least you’ll be able to tell people, “Hey this is coming. I feel your pain and we’re going to work to get it implemented as soon as we can,” that will make them feel so much better.
Other things to look for in the release notes, sometimes the release notes will have a basic how-to if the feature we’re talking about is particularly complicated. You briefly mentioned release notes as documentation, in a sense, they can be a little bit, very entry level documentation. When we’re doing help doc, we’re going to go into more detail, more information about something, but sometimes if you just need a really quick primer on something, the release notes can be a good place to start.

Gillian Bruce: So Mark, I would love to maybe ask you, switching your mindset a little … Clearly, you are a documentation superstar. If I’m an admin at an org, and I am building flow processes and all kinds of stuff, how should I think about documentation and incorporating some of maybe the best practices you’ve learned into my own processes?

Mark Ross: Documentation is really interesting, at least for me. I’m a nerd, obviously. It’s interesting because you can do so much with it, with just a little bit of time. I think that’s the hurdle that a lot of people feel, is finding the time to sit down and write something. But, if you release something for your users and you don’t write down how to do it, you’re automatically putting them at a bit of a disservice. Even if you train them in it face-to-face, that’s not the same as them having something they can come back to later. So just sitting down and writing the steps out, just do it, just make the time, find the time. Convince whoever’s in charge of your hours that it’s worth the time because it really is, it will save you so much trouble and will save your users so much frustration. So that’s the first step, just do it.
The second step is make sure that whatever you’re doing is clear and understandable. And I know that that is easier said than done, and not a very specific answer, but it is really important. If you’re using a new term, maybe you’ve named a new app, use that same term consistently. Don’t flop around with different versions of it, it will confuse users.
Hang on, my cat is being demanding. He’s being noisy.

Gillian Bruce: I couldn’t tell if that was child or an animal.

Mike Gerholdt: I couldn’t either, but that’s awesome.

Mark Ross: Ah, there. You’ve had some love, so are you happy now? Okay. Where was I?

Mike Gerholdt: What’s the cat’s name?

Mark Ross: Twiglet.

Gillian Bruce: Twiglet, that’s great.

Mark Ross: She’s a fat black-and-white cat, aren’t you? Yes. She’s a talker.
Using the same terms is important. Also, try to avoid really, really complicated language. If you can keep things simple, that’s going to be really helpful as well. Don’t use jargon, don’t use things, don’t assume that they know Salesforce terminology because they might not. Screenshots, screenshots. Again, they take time but they’re worth it, because you can literally point someone in the right direction. Anything you can do to help make things more clear, and not be vague, and not be too technical.
Those two things, just do it and be clear, those are the best things you can do.

Mike Gerholdt: Was there something you’ve learned, now that you’ve been writing documentation for a while, that you think could be really helpful for admins to know?

Mark Ross: I’m not sure, I’m not sure how to answer that. Frankly, as long as you’re … A lot of what I’ve learned since coming onto documentation is how to do proper technical documentation. So things like style guides, where there’s established written Wikis, or Confluences, or books like the Chicago Manual of Style, which professional writers have to use. That’s the difference between what I as an admin had to do, writing just documentation for my features, and then becoming a professional writer and having to write up to a certain standard, there is a bit of a gap there. I don’t think that gap is necessary to be bridged as an admin, I think it creates too much pressure and too much expectation.
I think, again, if you’re just writing something and you’re trying to write it clearly … That is definitely one of the things we look at, when I’m having my editor look at things, is clear. It has to be clear, it has to be understandable. Is it possible that however I wrote this could be interpreted in a different way? You would think the innocent pairing of words couldn’t possibly mean anything else, but it turns out, oh wait, this could actually be meant as something entirely different. So going back over your text after you’ve written it, and maybe making new versions of it. We call it iterating, on the team.
So I wrote something, but I’m not feeling that great about it. That’s fine, move on, come back. When you read through it again, oh there’s that sentence. You know what? Here’s another version, and just write it again, just make more iterations of that text until you get something. When you’re doing your own self edit, look for the things that might mean something entirely different if you look at it at just a different angle.
This is relatively high level documentation stuff, but sure, those are things that could be valuable. I’m not sure how well I answered that.

Mike Gerholdt: No, a lot of it is you learn what you don’t know. Some of it, I think to the point that you brought up, sometimes at least when I’m writing content, or working on something for a project, you’ll find you’re so close to it that you don’t remember to tell people what you innately know. I feel that with documentation. You’re so close to the app that you’re writing maybe these high level milestones, and in your brain you’re filling in the gaps because you know it already. And then, to the point that you brought up, you have someone else read it, well they don’t have those. Those gaps aren’t filled in, in their mind. That’s a really good point to bring up. The ability for someone else to read it, comprehend it and be up to speed is something you should always shoot for.

Mark Ross: That’s the other reason we say to avoid writing too technically, or writing with jargon, because that will automatically put you in the place where the user doesn’t know what you know.

Mike Gerholdt: Yes. Let’s tackle what is near and dear to just about every question I feel like I read on the community, which is error screen or error messages, and my flow doesn’t work. Because in your mind, I feel like we’re set up for success. Everything comes with a kit now, and a user guide, and you dump it out of the box, and you flip through it, and you snap everything together and boom, you got it. But with flow, you get to experiment, and you’re working with data, and rules, and limits. Sometimes, stuff just doesn’t work. How do you approach an error message? And what are you looking for in documentation that helps give you that moment of I know what to do next?

Mark Ross: Boy, error messages. They’re actually one of the hardest things, in my experience, to work on because you really got to make sure from a Salesforce perspective that it’s right.

Mike Gerholdt: Right.

Mark Ross: You’ve got to make sure you’ve got all the context, and that’s absolutely critical. If you’re going into an error message, you want to be sure you understand under what circumstances could this appear. Is it only in the UI? Is it going to also potentially show up in the API? Or, is it API only? If I’m doing some sort of push via API of a flow, is that the only way I’m going to see this error? That’s really critical.
You have to keep audience in mind as well. If you’re pushing something API only versus UI only, well API only, you’re probably going to have developers, and architects and highly advanced admins doing that, as opposed to something that appears just in the flow build of UI. Well, that is going to be anybody. Entry level flow people, they’re going to see this as well. We have to keep in mind audience, who we’re talking to, what level they’re at as well.
We also have to take into consideration when this appears, what could cause this to appear. And, is that going to necessitate how we’re actually writing this? All these little details are why error messages are really one of the hardest things we do. It’s actually one of my projects that I’ve been banging my head against lately, is a big set of error messages, because it is just so demanding. And, taking it in front of the developers and the engineers and saying, “Hey, does this look right?” And then taking it in front of the editor and saying, “Hey, what do you think of this?” It’s this back-and-forth process where we have to make sure this error message is really going to communicate, as clearly as possible.
And even then, these error messages are often going to be very specific. The devs, the engineers, they can only do so much. They really do try to cover every base they possibly can, but there’s nothing anybody can do to prevent any given admin from getting an unhandled fault for just some random thing that nobody could have predicted. That happens nine times out of 10. But, I have seen with my own eyes just how much effort they put into covering all the bases, because I know how many error messages I have to write.

Mike Gerholdt: Yeah, I can only imagine. The complexity, you have to think about how do we word this encompass quite a few things, too.

Mark Ross: Exactly, exactly. While not getting too out of hand, or being too narrow, so that it doesn’t cover all those bases.
The other thing … Sorry, this is actually really important. I should have said this. The other thing we try to do in our error messages, and I would recommend to anybody else whose doing anything like this, also include what the person whose reading the message can do.

Mike Gerholdt: Ah!

Mark Ross: That’s a really important thing. Because if you’re just saying, “Ah, this broke,” that’s not helpful. But if you’re saying, “Hey, this didn’t work. Try doing this. Or, remove this faulty thing. Or, add this first.” If you’re able to provide some amount of instruction, you’re automatically putting your users in a much better place than they were before.

Mike Gerholdt: Yeah. Thinking through, because you’re not there when the error message fires. You could be heading home from work, or walking the dog, or doing something and somebody in a call center hits an error message. It’s not like they have you immediately on speed dial, and they need to know exactly what to do next, so I think working through that. I also think a lot of the questions that I see in the community, too, are they’re getting error message while troubleshooting a flow, and trying to work through some of that documentation as well.
From a documentation standpoint, which I thought it was interesting to take this approach for a pod because we’ve talked about flow a lot and I’ve seen some really complex flows in my days. I’ve seen some really simple ones that have done amazing things. But, I think it’s another one of those things that we document at Salesforce, that we put documentation out, that we want our admins to document, of course. As admins are going through and there’s new features added, what is one of the things that you feel is foundational to understanding flow and automation, as opposed to chasing all the new shiny?

Mark Ross: Do you mean foundational in terms of it’s one of the first things you need to grasp before you can grasp the whole enchilada? Or, do you mean a greater concept?

Mike Gerholdt: I’ll give you an analogy related to cars. I feel, in my opinion, in order to learn how to really be able to drive a variety of vehicles and be a good driver, you need to know how to drive a manual stick shift. If you know how to drive a pre-1980 stick shift vehicle, you can drive anything.

Mark Ross: Oh boy. Wow. Okay. Because I can’t do stick shift, at all.

Mike Gerholdt: Well, that to me is one of those foundational … Because a lot of things have steering wheels, but outside of power steering and them sticking a million radio buttons on the steering wheel, that hasn’t changed, but the way vehicles move forward has changed. Now granted, I’m all in on EVs, and the power cycle, and everything how cars are evolving, but manuals are going to be around for while and it opened you up to a whole world of vehicles that are very exciting to drive. I feel it’s foundational because you also understand the mechanics of how the car moves. I’ve had to explain how you have to let off the clutch and give it gas, and it gives you an idea of what’s going on in the vehicle. You don’t have to do that with an automatic as much.
So what I was thinking of is, for example in Salesforce, I remember to the day that I was in the Admin 301 course with Wendy Braid, and she wrote on the board how objects relate to each other. She explained that, and man, I got it. It was the first time I got it. I felt like ever since then, it’s just been knocking over cards to learn new Salesforce features. Because once you understand how objects and stuff related to each other, to me it was caveat emptor, I can learn this product now.

Mark Ross: Gotcha, all right. Man, okay. Well in that context, picking only one is difficult.

Mike Gerholdt: Well you’re the guest, you can pick two. I just ask one.

Mark Ross: Well if we’re talking a single thing, it’s hard to pick just one. I would say variables is definitely one of the big ones. If you can understand variables, then you can handle almost anything in flow. Not just the concept of variable, even though I know that is one of the first hurdles that people have. This idea of okay, here’s a place I can store something. Okay, that’s great. Now that you understand what a variable is, now you have to understand how you can use it, and all the different types of variables there are.
There’s the variable itself, which is just a normal place to store data. You also have things like formulas, text templates, record variables, these are things that are also critical. They’re ways that you can store information, and calculate information if it’s a formula, that can then be used in other places. And then, you have to understand where are all the different places I can use this. And in flow that’s practically everywhere, that’s one of the prime realizations. It’s this idea that okay, well I’ve made a variable, now what do I do with it? It really is anything you want. You can use variables here, here, here, here, here, here, here. Same thing with formulas, same thing with text templates, same thing with record variables. If it’s something that you can make that’s like a variable in Salesforce in flow builder, it can be used almost anywhere for any purpose.
And then, there’s a whole nother level up from that, which is okay, how do you use variables properly instead of using them in not necessarily good ways like loops. You don’t ever, ever want to do a get records and update records, a create records, inside a loop. You don’t want to do that. Instead, you want to do that before you loop and store it in a variable. So that later on, within the loop, you can actually go use that information. That’s just a general practice of get all your data, manage all your data as much as you can before the loop.
Variables, I really feel are the one thing that, one, people look at as the first big hurdle, the first big thing that prevents them from using flow. But then, it also is … It’s like stick shift in that way, right?

Mike Gerholdt: Yeah.

Mark Ross: It also is the thing that, once you get it and once you know how to use it, you can do practically anything.

Mike Gerholdt: I think that’s good advice. I still am learning variables.

Mark Ross: I can’t really hear you. Should I hop off the VPN? We might have to use chat, because I’ve completely lost audio I think.

Mike Gerholdt: So true to COVID times, we had the internet drop out from underneath us so we got the last bit of Mark’s answer and we missed the wrap up. So I will say thank you, Mark, for being on the pod, that was fantastic. And, here’s the three things that we learned from our conversation with Mark.
First is there’s a lot of documented sources from release notes, to help, to Trailhead, and they’re all there to help you understand more about flow and Salesforce. You don’t have to read them all. So go through things very diligently, and look for information that is relevant to you.
The second is be cognizant about writing your own documentation. Use simple terms, and think of it as making sure that your users are there when you’re not. I would suggest, for sure, having someone else read your documentation. You can always revise it, you can always revise it.
And the third thing, I learned this asking Mark about what we should understand about flow, learn your variables. That seems to be, really, the one thing that you can do to understand flow. And once you understand that, as Mark said, you can do practically anything. So jump on over to Trailhead and learn about, well, practically anything with variables on flow. So that was super fun.
Speaking of podcasts, in today’s all digital world, being able to learn in demand skills is really more relevant than ever. You can access all of the amazing Trailhead content that you love, including 1000 plus badges of marketable skills, trail mixes and Trailhead live, all from your phone. This is my plug for you to go, download Trailhead Go. I’m going to put the link in the description, there’s a link that you can go to, you can download it. Or, you can search Trailhead Go in the Apple App Store or on Google Play.
Now, if you want to learn more about all things Salesforce admin, go to admin.salesforce.com to find those resources. You can stay up-to-date with us on social, we are @SalesforceAdmns, no I, on Twitter. Of course, you find my guest Mark on Twitter, he is @MarkRoss__C. Bet you know what that means. Gillian is also on Twitter, she is @GillianKBruce. And, I am @MikeGerholdt on Twitter. So send us a tweet, let us know if you loved this episode and suggestions for people we should have on. So with that, stay safe, stay awesome, and stay tuned for the next episode. We’ll see you in the cloud.