Remember the moment when you deploy a Flow and suddenly hundreds of records get errored out, emails go flying to the wrong customers, and Slack starts burning like Kings Landing? Yeah… same.
I’ve been building Salesforce Flows for a while now, but when I first started, it was all trial and error. I learned the hard way—so here are a few mistakes you can skip.
The 5 mistakes I made when building Salesforce Flows—and what I wish I’d known earlier.
Loopdeloop
Mistake - Built a Flow to loop through tens of thousands of records in production with record updates inside the loop. Didn’t realize this when building and testing the Flow in Sandbox (only had 30 records). This resulted in governor limits and flow failures.
Lesson Learnt - Always have DML operations (Create, Update, Delete) outside of the loop. Assign the variables inside the loop, collect the records and perform updates outside the loop.
Did you know?
The loop element has 3 main components -
-
Collection Variable - The record collection you want to loop through.
-
Loop Variable - Loop element iterates through the collection variable one-by-one and stores the value of the current item temporarily in Loop variable.
-
Direction - Specify the direction you want to loop through the collection variable items. First to Last or Last to First.
Hardcoding ID’s
Mistake - Hardcoded the Record Type ID. Record Type was different in Sandbox and Production which resulted in null pointer errors and flow failures.
Lesson Learnt - Query the Record Type Object using Get Records Flow element using Record Type Developer Name and store it in a variable to use it later in the flow. You can also use Custom Labels, Custom Settings and Custom Metadata.
Did you know?
- Custom Metadata in Flows - Use the
Get Record Elementand search for the Object (Custom Metadata Type Name) and you can filter the records based on the field values. - Custom Labels in Flows - Use formulas to access the Custom Labels within the Flow. These are located within the
{!$Label} Global Variable. - Custom Setting in Flows - Use formulas to access the Custom Settings within the Flow. These are located within the
{!$Setup} Global Variable.
Reusability
Mistake - Built multiple flows with same functionality. This resulted in complex flow logic, harder to read or manage and very difficult to troubleshoot errors.
Lesson Learnt - Build Subflows and call them from multiple Parent flows. Manageable, efficient and easier to debug.
Did you know?
You can call an Autolaunched Flow as Subflow from a Screen Flow, but you cannot call a Screen Flow as Subflow from an Autolaunched Flow. WHAT THE TONGUE TWISTER!!
Flow Entry Criteria
Mistake - Implemented a record-triggered flow with entry criteria checking if a field is a certain value ( Example: If a field has value of ‘10’, then update another field on the same record). In this scenario the Flow was triggered every time this record was updated, this resulted in an infinite loop. Those Salesforce error emails nearly gave me a heart attack.
Lesson Learnt - Always use formulas in entry criteria such as ISCHANGED() or PRIORVALUE(). This will only update the record when the field is updated.
Did you know?
You can build Complex formulas and use them as references when validating screen flow fields. Can also use them for visibility checks on these fields. Flows cannot be activated if you have an invalid formula - this such a good real-time troubleshooting feature for Admins.
Error Handling - Fault Path
Mistake - I was so proud of the first big Flow I built that I completely forgot to ask": what happens when Flow fails? Pushed the Flow to production and went to celebrate only to find out later the Flow broke and got stuck—and no one knew why. Result: CHAOS!
Lesson Learnt - Every flow should have a fault path. This can help notify and troubleshoot when flow fails. You can build a separate error log object in Salesforce to store errors using fault paths, this is more helpful when using autolaunched or record-triggered flows.
Did you know?
While you can send email notifications, display custom error messages on the User Interface and also create error logs using fault paths, the limitation is you cannot send Slack notifications for flow errors BUMMER! You will need to call an Apex class to bypass this limitation.
Final Flow-Thoughts
If there’s one thing I’ve learned, it’s this: Flows are the most powerful elixir for Admins in the field of automation, but can quickly turn into poison if you’re not careful. If you’re just getting started these 5 common mistakes can be your rite of passage—from chaos to clarity. This is just the beginning, but you’ll slowly get a hang of it, so build with intention and always try to follow best practices.
Winter might not be coming, but a Flow error sure is—unless you're ready.
