Navigating Flow Errors as a New Salesforce Admin

Today on the Salesforce Admins Podcast, we talk to David Simpson, Salesforce Admin at the 1916 Company.

Join us as we chat about his process for troubleshooting Flow errors and his unexpected path into the Salesforce ecosystem.

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

Why can Flow errors be so intimidating?

If you’ve ever received an emergency ticket from a user because they’ve encountered a Flow error, you know just how cryptic they can be. It’s not always clear at first glance what’s going on, or what your user can do to fix it.

What’s more, if you’re hearing about an error from a user, that means it’s made it to production. So now you need to start worrying about your testing and anything else that might pop up. And oh yeah, you need to fix the dang thing, too.

That’s why I was so excited to sit down this week with David Simpson. He’s doing a Dreamforce presentation about how to better navigate Flow errors and how to prevent them from happening in the first place.

Five steps to resolve a Flow error

David breaks down the process of fixing a Flow error into five steps:

1. Gather information about the Flow error. What’s in the error notification? Is it specific to a particular user or record?

2. Try to replicate the error in a sandbox environment.

3. Find the fix.

4. Test the fix in your sandbox, and test for any similar scenarios.

5. Push your fix to production.

David emphasizes the importance of communicating with stakeholders at every stage of your solve. You don’t need to share every single detail, but you want to make sure your user knows that you’ve identified the error, how long it will take to fix it, and if there are any workarounds in the meantime.

Reach out to the community

We also discuss David’s path from finance into the Salesforce ecosystem. He started out as a staff accountant, but when he was asked to take over some of the Salesforce administration duties, he realized he loved working with the platform far more than burying his head in spreadsheets.

Finally, I ask David about his top tips for getting better at solving Flow errors. He points to the Trailblazer community and Salesforce help articles as two of his best resources. However, he also suggests getting hands-on in a sandbox by trying to build things that might break. It’s a low-risk way to flex your problem-solving skills and will give you valuable experience for when a real error ends up in production.

Make sure to listen to our full conversation for more from David about how to solve Flow errors. And don’t forget to subscribe to the Salesforce Admins Podcast so you never miss an episode.

 

Podcast swag

• Salesforce Admins on the Trailhead Store

Learn more

• Navigating Flow Errors Session at Dreamforce

• True to the Core Deep Dive: Flow Testing and Debugging

• Test or Troubleshoot Flows With the Flow Builder Debugger

 

Admin Trailblazers Group

• Admin Trailblazers Community Group

Social

• David on LinkedIn

• Salesforce Admins on LinkedIn

• Salesforce Admins on X

• Mike on Bluesky social

• Mike on Threads

• Mike on X

 

Full show transcript

Mike: Ever had a flow error throw your day off track? You're not alone. This week on the podcast, we welcome David Simpson, Salesforce Admin at the 1916 Company who's bringing his session from Dreamforce navigating flow errors as a new admin right into your old earbuds. David's going to walk us through his process for troubleshooting errors, he shares tips for smarter flow testing, and we even talk about his unexpected path from finance into the Salesforce ecosystem. Now, if you've ever stared down an Apex exception email and wondered what is this trying to tell me? I promise you this episode is for you. So with that, let's get David on the podcast. So David, welcome to the podcast.

David Simpson: Thank you for having me.

Mike: Let's get started with what you do in the Salesforce ecosystem and the topic you're going to talk about at Dreamforce this year.

David Simpson: Sounds good. My name is David Simpson. I am a Salesforce Administrator at the 1916 Company. I have been an admin for a little over eight years now and a flownatic for over five years now, and my session is Navigating Flow Errors as a New Salesforce Administrator.

Mike: Okay, do you have a robe?

David Simpson: I had a cape from being an awesome admin back at Dreamforce 2018, but that has been lost in multiple moves.

Mike: Okay, well I'll say this publicly. I have an extra one in my basement and I'm going to get it after this podcast. You getting the cape back.

David Simpson: Sounds good to me.

Mike: So there we got that solved and all 35 people who are listening are like, cool, David's getting a cape, what else can I learn? But I saw your session. So navigating flow errors as a new administrator. I think for me, I've built demos for Flow. I am nowhere near Jennifer Lee level, Jennifer Lee's admin evangelist on my team. I think she knows more about Flow than Flow knows about itself. But I've always, I'll run into that error and be like, cool. I don't know Jennifer, what do I do? And for those people that don't have Jennifers, why are flow errors daunting?

David Simpson: Flow errors can be daunting first off because the error message itself can be very vague. You're dealing with developer query language and it might not be incredibly clear on first glance what the error is. So you have this issue where your end user or your stakeholder is stopped in doing their job, and they get some cryptic error that they don't know how they can fix it and they are now looking to you and now you have to decipher this cryptic error message. So it can be pretty daunting even when you have experience in the Salesforce ecosystem to know exactly where to go and what to do to solve that error.

Mike: So when do you find... New administrators, even experienced administrators get flow errors. Are you focused on when users get the flow error or when the admin is building a flow and testing it?

David Simpson: So it's actually both. My session is planning on covering what happens when you encounter an error, more specifically once it's live in your production environment and maybe somebody has encountered it and maybe your testing didn't cover that aspect. How you can handle that, how you can troubleshoot it and get to the bottom of it. But then also how you can do some more comprehensive testing when building your flows. So if you get those errors, you can adjust them immediately or you can read those errors and understand what you have to do without going through a bunch of help documents online and figuring out what that code means.

Mike: Yeah. So let's take us through David's thought process when you get a flow error. What happens?

David Simpson: So the first thing I do is I go see how I was notified of the flow error. If it is an Apex exception email, I'll read through the Apex exception email and try and see, okay, who caused this? What's the record? What step in the process did it fail? And just all of that information that's in those emails. Alternatively, if it happened to have been triggered via a Flows fault path, I will then investigate that notification. But then what I try to do is I first see what the error message is, if it's something that I'm familiar with, if it seems like it might be related to a validation rule or permissions or just general access, I'll see if I can address that quickly. But if it's something a little bit more convoluted or harder to decipher, normally what I like to do is to take that same flow and we have sandboxes, so I'll go into the sandbox and I'll just try to replicate those steps. I will perhaps use the flow debug and run it as the user who encountered the issue. Maybe I'll try and recreate the record if it feels like a particularly daunting error and then just run through the flow and see where it fails. Those are normally my processes and through that I will eventually encounter the cause of the error. And then at that point it's just going through the process of fixing the error in the flow, performing more tests to make sure that I've covered that as well as any other potential unexpected issues that might arise from the change and then getting that pushed out, all the while communicating to whoever encountered the issue that this is being taken care of, this is the ETA, and if possible, any workarounds for that fix and error.

Mike: Wow, you're better than the local mechanic that works on your car. Here's my car, it's making a noise. Three weeks later, you find anything out?

David Simpson: Yeah. With Salesforce, it's really nice because there is so much information that it can almost seem a little bit overwhelming, but that information can be used to get to the problem a lot faster. We're not getting just some generic error that says, oh, an issue occurred, good luck. We're getting a more specific error that is pointing us where we need to go. We just need to be able to translate that into human readable language in order to solve it.

Mike: Yeah, so I'm thinking of this. You've mentioned you've been an admin for eight years now, that's a decent time in the seat. How has working with Flow changed over time for you?

David Simpson: It has gotten so much better, so much easier, but also more complicated. I remember just a few years ago having to perform a process builder that triggers an auto-launched flow that might have some issues accessing certain records or a collection of records. And throughout the years with all of these releases and updates, it's just gotten a lot easier and more intuitive. A great example would be just the introduction of an auto-layout in a flow. Being able to see that clear process and order of operations to the flows, it's really helped. But also with all of these features, it does get a little bit more complex. What is the best element to put on your flow in order for this to not only run but run efficiently? Is it multiple update records? Is it doing a loop and an assignment and then an update? Is it using Transform? There's so many options and there's no particular right way to do a lot of stuff, which is really freeing. You can get super creative with these solutions and I think that that's been an awesome thing. And not to mention testing, going back to the flow errors. The recent introduction of an enhanced flow debug has really made my life a lot easier. I can see so much more detail in what's going on in my flows than what I just built. I can see the technical specs behind it, and that's really helped me narrow down what exactly needs to be done or what needs to be fixed in my flows when I do encounter an issue.

Mike: I'm going to say this respectfully. You sound like you have a lot of technical knowledge coming into the role of Salesforce Admin.

David Simpson: Oh, well thank you.

Mike: What was your history before being a Salesforce Admin?

David Simpson: Before I was a Salesforce Admin, I actually worked in accounting and finance. I was a staff accountant.

Mike: Oh, detail. Hello?

David Simpson: Yeah. Very process-oriented, very consistent in my day to day, and I at one point made a transition from being a staff accountant to a financial analyst, which was just essentially more spreadsheets. But during that time, my supervisor said, "Hey, I administer our Salesforce instance here. I think you'd be good at it. I need some help. Our professional services team, they put their opportunities in and we need to clean up their financials at the end of each month, but you should probably know the system in which they're putting this in." So he gave me an admin license and told me go on Trailhead, start learning some of the beginner stuff, and I just instantly fell in love with it. I love the problem solving aspect. I love the ability that there's so much you can do and build, that Salesforce is just a canvas of process creativity that I said, you know what? I don't think I want to do finance related work anymore. I want to do Salesforce full time.

Mike: Wow. Okay. So that's another podcast I'm going to have you on because I want to talk about career path. I think that'd be really cool, but I can see now the structured way that Flows work really could appeal to an accounting mindset. Is that the first feature that you really gravitated to?

David Simpson: Interesting that you asked that. It did take me a few years to get into the flow space and the automation space. When I became an admin, the first automations I touched were Workflow and a little bit of Process Builder, but I was really moreso focused on user access and just general custom object setup. It wasn't until a few years into being an admin that my manager, I had switched jobs, he said, "I need you to build this automation and it's not going to work in Process Builder. It's not going to work in Workflow. You'll have to do Flow." And I was very intimidated at the point. But I had a mentor who walked me through flows that they had built and it just clicked. It was so logical and just made so much sense while still being flexible that it was, I didn't go back to Workflows and Process Builders unless I absolutely needed to.

Mike: Yeah.

David Simpson: So yeah, it took a few years, but once I was on the flow train, I could not stop.

Mike: Yeah, no, I get you. I remember seeing Flow in its early early days back in 2012 when you used to have to actually download software to use it and the various iterations that it went through. But it's very useful now I think because of the visual aspect of it.

David Simpson: Yes.

Mike: I'm a very visual person and I've always, that's the thing that I loved about Process Builder was it looked like a process flow that you would diagram, and I'm glad that Flow has caught back up to that now.

David Simpson: Yeah.

Mike: Where do you stand on, so new admins, building flows, I've seen all kinds of flows. What's your process on how complicated you get a flow and testing it as you get more complicated?

David Simpson: Well, the complexity of a flow, I try to start by being simple first and only using some basic decision elements and update or create records elements, something that is really just a simple if/then statement and then add the complexities as the business requirements change. But with every single change that is made, I just test. That debug button is right there on the flow and is so easy to use. You just click it, pick a record or put your inputs in and let it run and just make sure that you're seeing everything that should be happening with each step. It's like cooking. You should be tasting as you go to make sure that nothing unexpected is happening. And you can do the same with the flow. You add a new element, you click the debug and you test it. You add a couple of decisions or a loop, click that debug and test it. So it can get as complicated or as complex as you need it to be. But you can also just start very simple and you can test along the way and it will come out fine, just provided that you're being proactive in your testing.

Mike: Yeah, no, sometimes I just dive in, I just want to build the whole thing and then it throws a million errors and I'm like, I should have built this more step-by-step. What was I thinking? It's the reason when they build houses, they home inspectors come at every stage. There's a reason for that. Let's talk about screen flows. I'm sure you touch on them in your session. I personally think they're really cool. I'm from, I was a Salesforce admin back in '06, and I remember thinking if only I could do a screen pop that walked people through filling out an account page or something, and now I could right? My fear if somebody turned me loose as an admin or I would do screen flows for everything. What is your decisioning on should I make this screen flow or not?

David Simpson: I am incredibly pro screen flow, much like yourself. In our company, we use screen flows for almost everything that requires end user interaction. The idea is to provide our users only what they need to interact with or change or take action on, and nothing beyond that for both an efficiency sake and also to make sure that there's no confusion or there's potential bad data. So we utilize opportunities to process our sales. We actually use Salesforce as our main point of sale, and when they go to close out their sales, they click a button which triggers a screen flow that says "Have you gotten all of your tasks in order for this opportunity? Do you have the opportunity products added? Are they available for sale? Have you synced this opportunity to our external system?" And then all they have to do is just fill out a few fields, probably less than a dozen throughout the entire screen flow, and then it completes the sale for them. Similarly, when they want to create a brand new sale, they click a button on the account that creates a screen flow instead of the new opportunity standard action. Because it has many less fields on it, they only need to fill out, okay, who the customer is, what's the deal name, and then some just basic additional info that our customer experience team likes to have. So it's a very streamlined process and we find that it not only saves them clicks, but it saves them time and gets them back to helping out their clients a lot faster. So I'm very much screen flow. I just gave an example about opportunities, but we use it throughout the entire Salesforce org.

Mike: Yeah, no, I'm with you. Pop a flow for everything. That'd be what I would do. So you're going to present this at Dreamforce next month. For people going, they'll see the presentation, not everybody goes and they listen. For people not going, but still really want to dig into what are things I should understand or how should I navigate flow errors as an administrator, what are some resources that helped you learn how to read through those error messages and understand them as a Salesforce administrator?

David Simpson: So the first thing I would suggest is the Trailblazer community. There are so many helpful people on those forums, and if you encounter an issue, you can post a question and in a matter of minutes you'll get a response. But they're also just generally friendly people and they just want to see you succeed and they will help you out. So that is an incredible resource. Just the community that is built up around Salesforce and administrators is so great, and I highly recommend that if you ever run into an issue that you check out the Trailblazer community. Additionally, the Salesforce help articles have been super helpful for me. They're a little bit more technical. They're more about the steps that a process or a system can do, but those are also great for getting a foundational knowledge. And then the third and final resource that I would say is just build and break in a sandbox. Just try to make things that don't work and see what happens, and then try to fix them. Because it's a sandbox and it's not real data you're not at risk of causing any issues. But I learned the most by making mistakes, by building a flow and maybe not testing it thoroughly enough or forgetting a field or forgetting a step where I get a certain record and then seeing what that error is and then adjusting that. That generally happens to all of us eventually, but try and do it deliberately and see what error results you get back. You'll be surprised to find that they're the same errors that you get when you're not trying to make mistakes. So a great way to learn is just by simply doing.

Mike: Yeah, I couldn't agree more. I'm from the days when you used to get a little help box and you just hit this most frustrating error and try it again, try it again, try it again. It goes back to that was it Thomas Edison, he didn't find one way to invent the light bulb, he found 99 ways to not invent the light bulb or something like that. I feel like we're all that way. I've found 99 different ways to make a flow not work out of trial and error. And sometimes that's all it takes. But you can only read so much and then you have to actually go do and try things out and poke around in the org. So last thing that's on my mind, and I wonder. AI in the last few years has just erupted. What in your job has changed because of AI? And I just mean in general. Doesn't have to be Agentforce, nothing like that. Just in general, has anything changed for you as an admin because of AI?

David Simpson: Yes. With the advent of AI, there is this unspoken expectation to be a little bit faster and a little bit more efficient. We are encouraged to use AI to help assist in creating solutions for the tasks that we are given and turn them around a little bit faster. It's just a general efficiency overall with AI. And I use AI in my day-to-day to help maybe create some tickets. We use Jira to spin up our tickets for the work that we need to do, and I will use AI to put my thoughts in. If I don't know a solution to something, I can say, "Give me the best recommended suggestions for implementing this type of action on the flow." Additionally, I can put in a solution that I've already had and have it output a nice format so that way if maybe I'm not the one doing the ticket, whoever I hand this off to, it can be much easier understood. So overall, just AI is making us more efficient and making us have a faster turnaround time, and that's just in turn building up the expectations for our stakeholders to deliver faster.

Mike: Yeah, plus now they're the ones feeding the error messages to AI being like I think I know what the answer is, David.

David Simpson: Yeah.

Mike: Really? Did AI tell you that? I bet it told you to go buy me a cookie and a coffee at Starbucks because if it didn't say that, then it was wrong. It's lying to you, Alice.

David Simpson: It's hallucinating.

Mike: It's hallucinating, Alice. AI's hallucinating. All right, David, this has been super fun. I look forward to your session. I will ping you after this and get you that cape because I have one downstairs and I don't like it when people lose their capes.

David Simpson: Sounds good.

Mike: We'll get that taken care of. Absolutely. Thanks for being on the podcast.

David Simpson: Yeah, thank you.

Mike: Big thanks to David Simpson for joining us and sharing his approach to navigating flow errors. Whether you're a new admin or just trying to make sense of that latest debug message, I think David's insights really offer some practical steps to take the fear out of flow troubleshooting. Now, I'd love for you to get the whole story. So if you're able to make his session at Dreamforce, that's great. If not, follow his tips and learn on Trailhead like he did. And I will say this, cape not required, but bonus if you do Trailhead with a cape on because I think that's really cool. Do me a favor, if you enjoyed this or you have friends that are navigating flow errors, share this episode with them and I would appreciate that. And until next time, we'll see you in the cloud.