Wed, 28 April 2021
Today on the Salesforce Admins Podcast, we’re back with the monthly retro. In this episode, we go over all the great blog posts, videos, and all the other Salesforce content from April.
You should subscribe for the full episode, but here are a few takeaways from our conversation between Mike and Gillian.
Blog highlights from April.
For Mike, “What Admins Need to Know About Salesforce Releases” was a must-read this month. It gives you the release timeline, links to resources, and everything you need to get ready. Gillian points to Mia Pacey’s blog about delivering business value.
Podcast highlights from April.
Mike had a blast talking with Mark Ross about how he and his team make Flow documentation. If you haven’t checked out his podcast, the Wizard Cast, it’s worth taking a listen. Another great episode from this month is our episode with Jen Lee about strategy and how to roll out new automations in your organization.
Video highlights from April.
LeeAnne Rimel’s Expert Corner is a great new series that gives you the experience of meeting with a subject matter specialist at Dreamforce or TrailheaDX. You should also check out No Silly Questions, where Gillian tries to answer any question submitted by the community or brings on an expert to help her get to the bottom of it.
Love our podcasts?
Subscribe today or review us on iTunes!
Wed, 21 April 2021
For this episode of the Salesforce Admins Podcast, we want to pull back the curtain and explain our process for prepping Release Readiness Live.
Join us as we talk about the questions we ask as we go through release notes, why it’s important to use different modes of communication to present key information, and how to find the throughline to tie it all together.
You should subscribe for the full episode, but here are a few takeaways from our conversation with Mike and Gillian.
Our Release Readiness Live prep process.
We thought it might be useful to talk about our own process for how we prep for Release Readiness Live content. “It’s one of the more fun parts about our job,” Gillian says, “it gives us an excuse to get tighter with our product organization and look through the incredible breadth of the platform.”
The first thing we consider is whether a new change or feature is something we’ve talked about before with admins. Some areas, like automations, have a bunch of new things continually added while others are one-offs or completely novel. We also consider if it’s an enhancement or something new. Finally, it’s important to highlight improvements to processes that can save steps along the way.
How to communicate changes and new features to your users.
Once we’ve done some processing from the release notes, we work with our content teams to get the information out there. That’s Release Readiness Live, but also demo videos, blog posts, and, of course, this podcast. You might not have the same resources that we have access to, but the important thing is finding a way to accommodate all the different ways people process information and get the key points across.
Most importantly, we’re always looking for a throughline—a story we can tell to put everything together. For example, you do a Slack post that updates a record that fires a new Flow that has a decision in it that does something else. In short, find a way to help your end users relate to the changes and understand how it impacts (and hopefully improves) their day-to-day.
We also wanted to highlight a few key dates for the Summer ‘21 Release:
Love our podcasts?
Subscribe today or review us on iTunes!
Thu, 15 April 2021
Today on the Salesforce Admins Podcast, we talk to Jen Lee, Lead Solution Designer at John Hancock, six-time MVP, and Salesforce Platform Champion. We’re continuing Automation April to learn how you can bring automation magic into your Salesforce instance and make your end users’ lives easier.
Join us as we talk about why you should go with the simplest automation solution for each problem, why you shouldn’t only think about the “happy path,” and how to learn more about Flow.
You should subscribe for the full episode, but here are a few takeaways from our conversation with Jen Lee.
Automation for Admins.
“I like being able to talk to the business users, understand what their business processes are, and then be able to automate those processes for them,” Jen says. She does just that in her day-to-day work as a Lead Solution Designer at John Hancock, but also in the content she creates for the community. Jen is the host of Automation Hour, a series that gives people a chance to present how they’ve used automation to make things easier in their org.
One important thing to realize is that automation doesn’t just impact user productivity—it can also be huge for admin productivity. Jen recently implemented a solution that goes back and removes a deactivated user from everything a week after they’ve been deactivated, saving admins from having to wade through public groups and permission sets and the like. “The admin doesn’t have to remember to do these things, the system remembers for them,” Jen says.
New Flow features.
Jen is excited about several new features that have come to Flows in recent releases. The first thing she highlights is improved functionality behind Record Trigger Flows, which will help you move processes to Flows. Another huge change is the inclusion of a link to Flow Builder in your dreaded Flow Fault email to help you pinpoint what’s going wrong without having to into debug logs.
If you’re looking to get started with Flow, Jen recommends getting started with the projects in Trailhead that focus on Flow. There are also some really great blogs out there that can help you along the way, and we’ve included her recommendations below. The community is generous and happy to help, so if you’re ever stuck make sure you reach out.
How to implement a new automation in your org.
When Jen is thinking about a new process or building a new automation for her org, she starts by talking with users to find out how they currently go through their process. It’s especially important to get them to break down how they know they need to do each step because that’s what you’re trying to automate.
Once you have the business process mapped out, you need to ask yourself: what is the simplest configuration you could use to implement it? “What fires off the process determines which path I take,” Jen says, “understand what triggers the process and then determine the best Flow or Process Builder option to take.” Keep in mind that you need to not only think about what happens when everything goes right, but also plan for and troubleshoot for what happens when everything goes wrong. As Jen put it, “don’t just think about the happy path.”
Jen also shares some ideas for how to train your users to work with new automations and show them how to integrate them into their daily routines, so make sure you listen to the full episode for more tips and tricks.
Love our podcasts?
Subscribe today or review us on iTunes!
Full Show Transcript
Gillian Bruce: Welcome to the Salesforce Admins podcast, where we talk about product, community and careers to help you be an awesome admin. Today we have another Automation April guest for you, because we are going to still focus on how you can bring automation magic into your Salesforce instance. Because as admins it's one of the most important things we can do, is help make our end users lives easier. And we can do that because we've got the tools with Salesforce to make that possible. Today, we are going to be talking with Jen Lee. Who's a lead solution designer at John Hancock. She's a six time MVP, a Salesforce Platform champion. She's also got lots of Salesforce certifications. She has a blog. She helps co-host something called Automation Hour, which we'll talk about. So without further ado to help talk more about automation in this month of April. Let's welcome Jen to the podcast.
Jen Lee: Thanks for having me.
Gillian Bruce: It's been long overdue to have you back on the pod. It's been been a while, so happy to have your voice back on the pod. Jen I'm sure many people, many listeners already know who you are, but I'd love to give you a chance to introduce yourself to maybe some listeners who aren't familiar with you. So Jen, can you tell us a little bit about who you are and what you do?
Jen Lee: Sure. I'm Jennifer Lee. I am based in Boston and I am a now six time MVP. So excited about that. I love automation. So we'll talk about that in a little bit, a little bit more about that. I currently work for John Hancock as a lead solution designer. So I work with all our agile squads to set best practices and governance standards for all our orgs and I review designs and review built solutions before they go to production.
Gillian Bruce: That is awesome. All right. So you said you love automation. I would love to hear a little bit about why you love automation.
Jen Lee: I like being able to talk to the business users, understand what their business processes are and then be able to declaratively or sometimes with a little bit of code help, be able to automate those processes for them. So taking manual steps and just with a click of a button, or if they make changes to record, be able to save that and then it does all the things for them. So that's just cool being able to help them and boost their productivity.
Gillian Bruce: Yeah. I think that's one of the core elements of being, what we like to call an awesome admin, right? Is being able to make our end users lives easier and help them do their jobs with less tasks involve. So let's talk a little bit about your expertise in automation and what you are doing in that space. So I know you've done a lot of content for the community on automation. Can you talk to us a little bit about kind of some of the main things that you do within the Trailblazer Community focused on automation?
Jen Lee: Oh, I forgot to even mention my blog in the intro. How did I forget that? I have a blog, jenwlee.com. I also co-host Automation Hour. So in Automation Hour, for example, we give people a forum to present automation and how they solutioned for the audience. So different skill sets, but we cover all things like Process Builder and Flow. But particularly what I focus on is, more so now, on Flow Builder and all the cool features that I could build with flow. I focus on things like the administrative side of things, the user maintenance side. For example, when you're deactivating a user, a lot of times admins don't go back and clean up all the other things that the user is part of. So like public groups, permission sets, cues, all those things. And at John Hancock, I built a solution that once we deactivate a user and a week afterwards, just to make sure that the user doesn't need to be activated again. We go and have an automated scheduled flow that goes through and removes them from all the things.
Gillian Bruce: So I think I love that story because what I hear this is like a automation that works for admin productivity, as opposed to just end user productivity.
Jen Lee: I even do things like, if we know certain users meet a certain criteria, we could add and remove permission sets accordingly or permission set groups, things like that. Again, the admin doesn't have to remember to add these people to those things. The system remembers for them.
Gillian Bruce: Oh, I love that. I love that. Less manual labor is always a good thing. So Jen, you mentioned, flow is definitely something that we are focused on here in Automation April as I kind of dubbing it. What are some things that are kind of newer in flow that you think admin should pay attention to because they either make you excited or you see some great value props from them?
Jen Lee: Yeah. And I want to give props to the PMs of automation because they continue to add such great features with each release. So some of the things to look out for is now there's a lot more functionality behind record triggered flows. So now you can take your processes and start moving them to flows because Flow Builder's going to be the end state automation tool. So you can now remediate that tech debt, where you have all these processes and start moving them to flow. They've done a lot in terms of helping out with debugging flows. So one of the most recent changes in the last release was now when you get that ugly looking flow fault email, it includes a link to the Flow Builder. So you click on that. It takes you directly into Flow Builder where your flow faulted. And so now you could visually see where the record went and then it stopped.
Gillian Bruce: So I vividly remember Jen, the first time that I tried to use flow and it was the old Cloud Designer. Oh my goodness. And I remember, I didn't even understand what a variable was. And I was so confused because I felt like I was having to create six things in order to just do a two or three step flow. Especially not being from a developer background, I didn't even understand these concepts. I'm like, "What is an SObject? What is a variable? Why do I need to set these things? What is this language I'm using? I don't get it." So when you mentioned that, with the new version of flow, which is amazing. The fact that Salesforce automate some of that, might make it a little easier for anyone who got a little intimidated by flow in previous years to kind of maybe think about diving in to flow land. I keep naming different lands on this podcast. I don't even know how many there are at this point.
Jen Lee: So I had a very similar experience to what you had when you first started with Cloud Flow Designer. I opened up that blank canvas and saw variable. What's a variable? What's the SObject stuff. And I immediately closed the browser. I'm like, "I don't know what this is. I have no idea." And I eventually kept at it and I am where I am today because I was persistent. But I totally understand if you started off with that and you looked at that, you're like, "Okay, this is so complex." You really did need a developer mindset to understand what it was that you needed to do. So I would say, "Okay, now is the time, where it's okay to go into Flow Builder."
Gillian Bruce: I love it. Yeah, the generosity of the Trailblazer Community always blows me away about how people are so willing to spend their time to help someone else learn. Just a simple little thing or troubleshoot a simple issue. And then it just grows from there. It's incredible. It's incredible. So Jen, can you also talk to us a little bit about your overarching strategy. You talked earlier about, the use case that you had, automatically removing a user, a deactivated user from processes. When you're developing a new process, or thinking about bringing a new type of automation into your org. What are kind of the first steps that you take? Maybe even before you start building it. How do you figure out what you need to build? What kind of teams and meetings and stuff do you set up? Talk to us a little bit about that.
Jen Lee: So if it's benefiting the user, I would typically talk to the user and have them show me the steps that they currently take to do X, whatever it is, that they're doing. And literally step through the process and I'll say, "How do you know you had to put this value in there." Because sometimes when they're clicking, they're not talking through the things that they determine in their head. Because ultimately when you're building out automation, you need to be able to know those things and tell Salesforce what they need to do or how. Or I need to get this account information. How did I know which account to get?
Gillian Bruce: I love that. I liked the verification step that you just mentioned too. First you kind of do your investigation with asking the user the very detailed questions of why did you put that there? Where did that come from?
Jen Lee: With the five whys, why did you do that? Why? Why?
Gillian Bruce: Right. Channel your inner toddler and just drive them a little crazy, but it'll work. It'll make them happier in the end. And then the verification of showing them the process that then you've mapped out based on what they've showed you. And then getting the like, "Yes, that's what we do." Or maybe, "No, you skipped a step." Or "That's not how that's related." I think that's really important to think about.
Jen Lee: So once I understand the requirements or business process, then I'll think through, what's the simplest configuration that I could use. Maybe it might not be flow. Maybe it's just a quick action that takes you to the page with fields, and then that's how you submit it and save it. So if it is automation, then I'll figure out, do I go the Process Builder route? Is it something that's a record change? And then it does other things, or can I start in flow directly. Figuring out what fires off the process, determines which path I take. So if it requires collecting information then I know that, that's a screen flow. If it's something that happens on a schedule basis and that's scheduled flow. So it's like understanding what triggers the process and then determining the best flow option or Process Builder option to take.
Gillian Bruce: I love that. Don't just think about the happy path. It's very important to remember. Because I think sometimes we work so hard to build something and you just are so focused on how cool that is and it works and it's so great. But you got to remember, users are going to do all kinds of stuff and you never know.
Jen Lee: Exactly. And you're like, "Why did you do that? I didn't even think of that situation." So then you have to go back and build that situation in. Yep.
Gillian Bruce: Yeah. Again, kind of going back to a toddler analogy since I have one. It's like thinking about all the possible things that they might do to destroy something, right?
Jen Lee: Exactly.
Gillian Bruce: You got to move the sharp objects, another shelf up, or you've got to put the door knob protector on there, all of the different things. So let's then talk about kind of rolling a new automation out to your users. So you've got it built, you've tested it, it works. What are some strategies? Because you don't work at a small organization. Tell us a little bit about how you roll out a new feature set or a new process to your user base.
Jen Lee: So depending on how many users we're touching, we might in our release, provide release notes to let folks know, hey, there's a change coming. Sometimes when it's automation, it might be just transparent to them, and they shouldn't need to know that something's changed behind the scenes. But if it's something that's taking manual steps and automating it, we would typically maybe do a video clip and send it out to the users, or on Lightning, you could use that in-app guidance. And for a period of time, if they're going on a page where you have that automation, give them a heads up. Here's what's different now, to let them know.
Gillian Bruce: Yeah. It's a very good point about the in-app guidance. It's a great tool for any admin looking to roll out anything. So Jen, I would love to kind of, before we wrap, have a little fun. So Jen, you have been in the Salesforce ecosystem for a while and in the Trailblazer Community. I would love to know what is one of the most interesting or funny, maybe use cases or demos, that you have seen from either in your own that you've built as an example or somebody else in the community who shared something that kind of made you giggle?
Jen Lee: I know I saw someone build automation where they use it to play a Blackjack game. And I thought that was an interesting thing. And I forget if it was Dreamforce or it was a webinar or something. But yeah, I thought that was an interesting use case to build with automation. I wouldn't have ever thought about that.
Gillian Bruce: I wouldn't either. There you go. I like it. That's great. All right. So any kind of last parting thoughts or pieces of advice you love to leave our amazing, awesome admin listeners about automation in general? Before we wrap up today.
Jen Lee: Create that automation because that's really using your awesome admin powers to help out your users and increase their productivity.
Gillian Bruce: I love it. Simple, great, powerful. Jen, thank you so much for joining us on the podcast today. I really appreciate it. And I so appreciate all the work you do with Automation Hour and your blog. I know it helps thousands and thousands of awesome admins in the community. So thank you.
Jen Lee: Thanks Gillian for having me back.
Gillian Bruce: Well, huge thanks to Jen for taking the time to chat with me. It's always great to catch up with her and of course talk about all things automation. So for my top takeaways from our chat with Jen today is first of all, when you're thinking about implementing or designing an automated solution for your users, go with the simplest path possible. As Jen says, that is going to set you up for success in the longterm. It's also going to make your job easier. So really think about what type of automation is needed. Is it something where you need to capture information, in which Jen suggests using Screen Flow? Is it something where when a record changes, other actions need to happen? This is where you really determine which type of automation you are going to build.
Thu, 8 April 2021
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 (Community, Content, and 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.
Love our podcasts?
Subscribe today or review us on iTunes!
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.
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 community and content experience team, 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.
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."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.