Skip to main content

Flow Meta Conventions

Read these first

  1. The official Flows best practice doc. Note we agree on most things.https://help.salesforce.com/articleView?id=flow_prep_bestpractices.htm&type=0

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

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

 

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.

 

  1. Record-Triggered Flows, Process Builders, and Triggers should never coexist on the same object.
    Also note the "What automation do I use" flowchart.
    Yes, we know this is overly restrictive, but this describes the best practice. If you have Processes and want to leverage Record-Triggered Flows, you should be slowly migrating all of these Process Builders to Flows. Same if you start relying on APEX Triggers - while this doesn’t mean you have to change all the Flows to APEX logic straight away, it does mean you need to plan for a migration path.

    In the case were some automations need to be admin editable but other automations require custom code, you should be migrating the Triggers to APEX, and leveraging sub-flows which get called from your APEX logic.

  2. Flow List Views should be used to sort and manage access to your Flows easily.
    The default list view is not as useful as others can be.
    It is exceedingly important that you show the fields “is using an older version” and “process type”.
    You should also create Views for Active Flows and Non-Active Flows.

  3. Flows are considered Code for maintenance purposes
    Do NOT create or edit one in Production, especially a Record-Triggered flow.
    If any user does a data load operation and you corrupt swaths of data, you will know the meaning of “getting gray hairs”, unless you have a backup - which I am guessing you will not have if you were doing live edits in production.

  4. If at all possible, Flows should be Tested
    (currently using Test classes - later down the line I expect Salesforce will make Test Flows available)

  5. When creating automations, the order of priority should be:

    1. Object-bound, BEFORE Flows
      These are the most CPU-efficient Flows to create.
      They should be used to set information that is required on Objects that are created or updated.

    2. User-bound Flows
      Meaning Screen flows. These aren’t tied to automation, and so are very CPU efficient and testable.

    3. Object-bound, Batch Flows
      If you can, create your flows as a Batch rather than something that will spend a lot of time waiting for an action - a great example of this are scheduled emails one month after something happens.
      Do test your batch before deploying it, though.

    4. Object-bound, AFTER Flows
      These are last because they are CPU intensive, can cause recursion, and generally can have more impact in the org than other sources of autmation.

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

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

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

  9. On a related note, Don't use non-official components without checking their limits.
    Yes UnofficialSF is great, and it also contains components that are not bulkified or contain bugs. To reiterate, if you install unpackaged code in your organization, YOU are responsible for maintaining it.

 

No Comments
Back to top