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.
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).
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
The official Salesforce Architects guides, especially the one about Record Triggered Automation but it’s not quite up to date for Winter '22 yet.
SFXD Wiki whilst I do NOT agree with their naming convention nor their “1 per Object and Operation” I do really appreciate the effort and thought that has gone into this series of documents.
Salesforce Admins - I actually like this one! And it seems to have been re-posted on the Architects Medium also (or the other way round). And then Monica Sandberg did a great video showing her processes for using these rules. Check out her Naming Convention!
10 Commandments - I like this one as it’s straight to the point and basically follows what I think also, at least he justifies the One X per Y and tells you to think about it.
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).
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.
A great intro post from Jessie Rymph explaining Invocable Apex.
A really detailed developer-centric look at Invocable Apex.
Is there other ways to achieve this
Think of DLRS, and Mass Action Scheduler
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.
How are you going to Name your Flows?
My Naming Convention is… Object_BeforeOrAfterCreateOrUpdate_Criteria
Account_BeforeCreateUpdate_Always
Opportunity_AfterUpdate_IsWon
Case_AfterUpdate_IsClosedWithEmail
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.
See my Japan Dreamin Talk
Can a Quick Action be used instead?
See my London’s Calling Talk and my page on Actions
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!
Does your Flow involve updating a field with a value from a Formula?
No Before Save Flows for you.
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.
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.
External Services?
If you have the right use-case AND can have some control over the API OR are willing to write and maintain your own Spec
LWCs in Flows?
OR better still, LWCs instead of Screen Flows…
The Lightning Record is really cool and easy to work with.
Flow Solutions and Components!
Bottom line is HAVE FUN!