Flows - Question Everything

This is not about best practices… there are many people that are writing many things about best practices, and I will link to some of them… but it’s about questions you need to ask as you are thinking about Flows, working on building Flows, and using Flows. Hopefully thinking things through will help you create better, more robust Flows.

Be Opinionated

This post is VERY opinionated. My opinions may NOT fit with your thinking about Flows or coding or Salesforce in general. But I write from a perspective of being a Salesforce Administrator / Developer / Consultant / Architect (and all the rest of the titles) but only working on small to medium businesses. So take note, that I understand that if you work in large or enterprises or where your Salesforce org does critical things like health and banking then go and read something else.

Also, if your org is only hand-crafted artisanal code and you’ve never installed a Managed Package or an AppExchange app, and you pride yourself on having nothing but code that has gone through 16 rounds of both manual and automated code review, and only been added to production via a CI/CD process and no human hands have touched it, then look away.

But if you live in the real world where we are building functionality on top of the Salesforce platform, utilising ALL that it has to offer, and have a heap of AppExchange apps and Managed Packages because we trust that others can write better apps than us, then this post might be for you. (Almost 10 years ago I wrote this post about thinking like Salesforce, - except replace Flow for Workflow Rule and LWC for Visualforce Page - and it still holds very true today).

Best Practices

OK, so I said I would link to a few best practices documents… I don’t agree with them all, but here’s a few

One X Per Y (or Process Builder is D.E.D. Dead)

If you are reading any documentation on Flows or Process Builder or anything and come across rules that declare MUSTs then just stop to think about why they are saying this. The declaration by Salesforce (even still to this day baked into the UI), saying you should only build one Process Builder per Object was one of the top ever 10 bad decisions by Salesforce (this is a whole other post). Just ignore it. Ignore that it was ever a thing. Ignore that Process Builder was ever a thing. Move on. Go back to learning about how Workflow Rules taught you to do automations and start from that basis of thinking.


Do you know your Order of Execution like the back of your hand? Nope? Then start there… I like this diagram but it’s not up to date with Before-Save Flows. You need to know what is happening when you click the Save Button or send a record into Salesforce by one of the many Integration options, (and no Mulesoft != Integration, but that’s another post).


Before thinking of Flows

  • To Flow or to Code?

    • It's not an either / or

    • Try thinking of Flow as similar to Apex Triggers (but built in a way that business can modify them more easily) and create Invocable Apex to do the hard logic.

  • Is there other ways to achieve this

  • Is a Workflow rule enough?

    • Eg email alerts

    • Approval Processes

    • I would have said Time-Based Workflow until recently but now that is fixed and you can use them in Flows.

    • It’s still OK to do a Workflow Rule if it’s just one or two simple updates on an object that’s not used much… but it’s probably much nicer to start building Flows.

  • Have you been scared off Flows?

    • Re-think what people are telling you! Why are they telling you this? What horror stories have they seen? Is the same thing likely in your org? Nope? Then go with the Flow.

Before Building

  • How are you going to Name your Flows?

    • My Naming Convention is… Object_BeforeOrAfterCreateOrUpdate_Criteria

    • It doesn’t really matter but…

      • Be consistent

      • Name them in such a way you can group ALL Active Account Flows in one list view

  • To Subflow or not to Subflow

    • Think of the options

      • Eg Send an Email, Assign a Topic, Send a Notification may be good candidates for Subflows - this is where you will be reusing them.

    • What are your "guidelines"?

      • I don’t like the idea that everything can go into One Flow with Subflows… like trigger logic. But it’s definitely an option. I just think my Flow would get far too unwieldy and processes that only happen occasionally obstruct looking at the core processes.

    • Have you built one big flow and now need to break them into Subflows?

      • There’s no easy way at the moment

    • Multiple Flows are fine, as long as you know that if two Flows are run on the same transaction you can’t determine which runs first.

  • How will the Flow be invoked?

    • Does it need a screen Flow

      • Hours and hours can be spent building Screen Flows when a simple button or Checkbox may be enough.

      • Can a Quick Action be used instead?

      • Record Fields are NOT ready for prime time yet, and did not get any updates in the current release.

      • I’ve not found a Screen Flow Lookup component that actually works and looks and functions like standard.

  • When does the Flow need actually need to run?

    • Does everything really really need to be immediate in the exact same transaction? Maybe not… try the new options of

      • Asynchronous

        • like @ Future annotations in Code

      • Scheduled Paths

    • Pause Elements are a little limiting since they can only be run in Autolaunched Flows

      • See my Automation Hour talk

      • Alternatively try to save a value to a record then run a record-triggered flow off that… but test to ensure it doesn’t run into limits if it’s on the same record.

    • Beware of Scheduled Flows - TEST, Test, then re-test

      • Yeah, I really badly stuffed up!

During Building

  • Does your Flow involve updating a field with a value from a Formula?

  • Is your record updated by an external System?

    • I have not found Before Save Flows safe in this instance

  • Can you actually use a Before Save?

    • Try, but in practice it’s not fabulous… and then is it really worthwhile maintaining two Flows, or just move everything to After-Save.

    • Eg DLRS updates a field via a Trigger, which runs after Before Save, so your Flow needs to run after that.

  • Do you have formula fields that rely on other formulas

    • Eg Rate1 * %1 = Fee1, Rate2 * %2 = Fee2, then TotalFees = Fee1+Fee2

    • Maybe do one in a Before Save then one in an After Save

    • They say don’t do same-object field updates in After-Save Flows but I have found it to be necessary.

  • Do you REALLY need that Flow Loop?

    • Have a look at the Collections collection

      • Eg to get a comma separated field of names of contacts where they have the same email address as the existing contact, use Extract Strings from Collection

    • How many records will you be updating at any one time?

      • Can you control the batch sizes? There are new Batch Sizes options in Asynchronous and Scheduled Flows. Otherwise Mass Action Scheduler is amazing for that.

After Building Flows

  • Versions

    • All new features will be released with Flow Versions

  • Keep up to date

    • Eg all your early Before Save Flows with Assignments and not Record Updates will still work, but update them to be sure.

  • New Features

    • Eg I now need to re-build my Flows with Subflows on After-Save Flows


  • Start Moving Process Builders

    • D.E.D. Dead. Get rid of them. Make it your mission!

  • Or Simple Before-Save updates from Workflow Rules

  • Maybe leave Emails until last (Emails in Salesforce generally are still a complete mess, apart from you can now use Lightning Email Templates in Auto Emails, but that’s a whole other topic).

  • There is no real hurry, only do it if you are working on improvements, or the Process Builders are sooooo horrible that you just neeeed to delete them to save your sanity, or there are performance issues that are bugging you.

What else to do with Flows?


Bottom line is HAVE FUN!