Flow Meta Conventions
Read these first
- The official Flows best practice doc. Note we agree on most things. https://help.salesforce.com/articleView?id=flow_prep_bestpractices.htm&type=0
- The Flows limits doc. If you don't know the platform limits, how can you build around them? https://help.salesforce.com/articleView?id=flow_considerations_limit.htm&type=0
- The Transactions limits doc. Same as above, gotta know limits to play around them. https://help.salesforce.com/articleView?id=flow_considerations_limit_transaction.htm&type=0
SFXD Best Practices
These are general best practices that do not pertain to individual flows but more to Flows in regards to their usage within an Organization.
- Record-Triggered Flows, Process Builders, and Triggers should never coexist on the same object. Also note the "What automation do I use" flowchart. Also use the fact that Salseforce itself only recommends one source of automation per Object.
- Flows are considered Code for maintenance purposes - do NOT create or edit one in Production, especially a Record-Triggered flow.
- If at all possible, Flows should be Tested (currently using Test classes - later down the line I expect Salesforce will make Test Flows available
- Flows that call APEX or LWCs are subject to more limits and potential bugs than fully declarative ones. When planning to do one, factor in the maintenance cost of these parts. Yes, this absolutely includes actions and components from the wonderful UnofficialSF. If you install unpackaged code in your organization, YOU are responsible for maintaining it.
- When possible, prefer user-triggered automations. Then, scheduled batch automations. And finally, record-triggered automations. If you're sending emails there's a high probability you can just iterate over all records matching criteria and send them instead of adding a record-triggered decision node.
- Record-triggered flows are BLEEDING EDGE and not ready for prime time. Amongst other things, you can't debug them properly without workarounds. You might want to wait for Winter22 to use them extensively.
- Use System mode sparingly. It is dangerous. If used in a Communities setting, I REALLY hope you know why you're exposing data publicly over the internet or that you're only committing information with no GETs.
- Flow List Views should be used to sort and manage access to your Flows easily - more on that in Naming Conventions
- APEX or LWCs that are specifically made to be called from Flows should be clearly named and defined in a way that makes their identification and maintenance easier.
- Do not design Flows that will have long Wait elements and will be called by thousands of records. You'll exceed your Paused Interview limits. This kind of use case it should be a Scheduled flow anyway.