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.