7

One Record Triggered Flow Per Object Per Type

As per flow best practices in Salesforce we should create one record triggered flow per object per type/event. This idea come from Apex trigger framework. As we can create multiple record trigger flow, but it will be difficult to manage those multiple flows. Better we can create two trigger flow for each object, one for before save operation and one for after save operation. In those before and after trigger flow, we can create decision elements and based on decision result we can call sub flows.

Do not create more than one record Triggered flow on any object per type. Follow below Naming Convention for record trigger flow– <ObjectName><event RType>.

  1. ContactBeforeSave
  2. ContactAfterSave
One Record Triggered Flow Per Object Per Type/Event

Advantage of one record triggered flow per object

  1. Creating one Flow per object will enable create reusable Flows and manage all your Flows for a given object in one place.
  2. When you have just one Flow per object per type, You may hit governor limits – such as number of SOQL queries; furthermore,
  3. Adding one Flow per object rule will also allow you to avoid generating infinite loops.
  4. One per object is the only way to enforce order of execution, and if you can’t control that, your troubleshooting will be very difficult.

Step by Step Process for Flow Design Pattern

Let see how we can create Salesforce Flow Design Patterns for “one record triggered flow per object per type/event” with step by step process.

Step 1) Create Record-Triggered Flow

Create record triggered flow and select the before and after event. Don’t add the flow entry criteria so that it will execute every time when record will created or updated. Let take a example for before Account triggered flow. Consider this as your Handler class in Trigger framework.

Before Record triggered Flow

Step 2) Time to execute the Action.

In flow builder, we need to create a Decision flow element. Add condition for the in decision flow element like below screen

Decision flow element

Step 3) Time to add the Action element

Now, Call sub flow or add your flow execution logic like below screen

Salesforce Flow Design Pattern

Step 4) Add more Action

Once your action is done in flow then connect the regular connector from the Update Records flow element to the next decision (i.e. “criteria node”) to execute the next flow.

regular connector from the Update Records flow element to the next decision

You might be thinking about this flow will be very big soon. Answer is yes. I highly recommend don’t action element directly here and use Sub-Flow(s) for actions.

Now you may have some question in your mind.

Execute only on Insert?

May be now you have a question if we select the “Trigger the flow when” as “A record is created or updated” then it will execute on insert and update both. But what about if you want to execute some “Decision flow” only on record creation (insert)?

The answer is use ISNEW() function in your Decision flow element. Create one function like below first

ISNEW function in Salesforce flow

Then use same the same in your “Decision flow element” like below.

NOTE: I also recommenced to use ISCHANGED() for “Decision flow element” to make sure it will only execute when field value changed. It will avoid extra execution for flow element.

Use Sub Flow

Now you might thinking of you will create only one Trigger flow per object then my flow will be too big very soon. Answer is yes. How we can avoid it ? Now I will recommend to use sub-flow(s) for any logic. Subflows are a sequence of reusable actions that one can use in a Flow.

Summery

Creating one Flow per object will enable you to achieve flexibility, create reusable Flows, and manage all your Flows for a given object in one place. Follow Naming convention for that same flow can be reuse. Now Record-Triggered Flow is a great alternative to Process Builder.

If you are new to Salesforce flow then check our FREE Salesforce Flow Training here.

Comments(7)

  1. Reply
    Andy Engin Utkan says:

    Thanks for the post. My understanding is that there is no recommendation from Salesforce that says this. Please check and provide a source.

    • Reply
      Amit Chaudhary says:

      This idea come from Apex trigger framework. One flow per object is the only way to enforce order of execution and if you can’t control that, your troubleshooting will be very difficult and soon you will hit the governor limits.

      • Reply
        Andy Engin Utkan says:

        Thank you for all you do Amit. Great discussion. While it is a very valid recommendation, the beginning of the post sounds like this is a best practice supported by Salesforce, however it is not at this point. That’s what I wanted to point out.
        The reason Salesforce does not recommend this today (my understanding) is as follows:
        – You may have multiple flows running on the same object, and you can limit the cases the flows trigger by defining a narrow entry criteria (start condition). The defined case criteria can be mutually exclusive. This means that you will be running one flow at a time if you do this right, and even zero flows in some cases.
        – As you try and bring all these flow elements in one flow together, you will find yourself in a situation where you run this combined flow on almost every record create/update. However, the real performance gain is achieved when you don’t trigger your flow at all.
        – As you build out your flow, you may want to use subflows for repeating logic, and if you do, you must run your combined flow in after-save mode. You will lose the speed and efficiency of the before-save update. Subflows are not available for before-save flows as of today.

        • Reply
          Zagaio says:

          @Andy could you elaborate on “As you try and bring all these flow elements in one flow together, you will find yourself in a situation where you run this combined flow on almost every record create/update. However, the real performance gain is achieved when you don’t trigger your flow at all.”

          Specially the last part “the real performance gain is achieved when you don’t trigger your flow at all.”
          How does this work? When your decisions elements are not met nothing happens right? So how would that impact your performance?

  2. Reply
    jele says:

    is there a recording about this?

  3. Reply
    Trinetra Rawls says:

    This is a great post but it poses a question about record triggered flows..
    I’m creating a record triggered flow to update the opportunity amount field if a budget item is created or updated. The flow loops through all budget items and calculates the total and updates the amount field. If a budget item is deleted, I will also need the flow to loop through and recalculate the total amount. How can I add this piece of the puzzle to the existing flow?

  4. Reply
    Neel says:

    Hi All,
    I want to pass $record and $record_Prior variable to Subflow, is there any way to do that ?

Post a comment