...
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 pre-recording
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.
...