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

 

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.

 

  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, Alsowe useknow this is overly restrictive, but this describes the factbest 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 Salseforceyou itselfshow onlythe recommendsfields one“is sourceusing ofan automationolder perversion” Object.and “process type”.
    You should also create Views for Active Flows and Non-Active Flows.

  3. Flows are considered Code for maintenance purposes - do
    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 availableavailable)

  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 callis APEXrequired on Objects that are created or LWCsupdated.

    2. User-bound Flows
      Meaning Screen flows. These aren’t tied to automation, and so are subjectvery toCPU 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 limits and potential bugs than fully declarative ones. When planning to do one, factorimpact in the maintenanceorg costthan other sources of theseautmation.

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

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

  9. Flow List Views should be used to sort and manage access to your Flows easily - more on that in Naming Conventions

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

  11. Do not design

    Flows that willcall haveAPEX longor WaitLWCs elementsare subject to more limits and willpotential bebugs calledthan byfully thousandsdeclarative ones.
    When planning to do one, factor in the maintenance cost of records.these  You'llparts.
    Yes, exceedthis absolutely includes actions and components from the wonderful UnofficialSF. If you install unpackaged code in your Pausedorganization, InterviewYOU limits.are Thisresponsible kindfor ofmaintaining it.

  12. On a related note, Don't use casenon-official components without checking their limits.
    Yes UnofficialSF is great, and it shouldalso becontains acomponents Scheduledthat floware anyway.not bulkified or contain bugs. To reiterate, if you install unpackaged code in your organization, YOU are responsible for maintaining it.

 

 

Back to top