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
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.
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.
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.
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
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.
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?
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