Last Updated on May 31, 2022 by Rakesh Gupta

This is a continuation of my last article Salesforce Flow Design Patterns – from Fundamentals to Mastery. In my previous article, I discussed various best practices and design considerations when it comes to building an efficient Flow. This article goes a step further and explains how a user can create, and manage, ‘Per Object – Per Type Record-Triggered’ Flow!

A-One Record-Triggered Flow per Object Design Pattern simply means having one Flow per Object to handle all business logic on a given Object.

Advantages of one Flow per Object – per Type include:

• Reusability – Putting logic into SubFlow will help you to improve re-usability. You can call a SubFlow even from an Apex Code.
• Reducing Complexity – Less likely to hit limits – such as the number of SOQL queries. Adhering to the one Flow per Object rule will also allow you to avoid generating infinite loops.
• Optimize for Clarity – To keep record-triggered flow compact and maintainable, I strongly recommend taking the object-oriented approach and applying the same principle in the record-trigger flow. It will also improve the understanding and readability of flow.

Creating One Flow Per Object – Per Type idea comes from Apex Trigger best practice and design pattern. Creating one Flow per Object will enable a user to achieve flexibility, create reusable Flows, and manage all Flows for a given Object in one place.

Unfortunately, as of the Winter’22 release, it is not possible to create a one Record-Trigger Flow with all Trigger events. Record-Triggered Flow only support the following events:

• Before insert
• After inset
• Before update
• After update
• Before delete

If so then, let us use One Record-Triggered Flow Per Object framework to create the following Record-Triggered Flow on every Object instead of creating multiple After-Save or Before-Save Record-Triggered Flow on a specific Object.

1. Record-Trigger: ObjectName Before Save
2. Record-Trigger: ObjectName Before Delete
3. Record-Trigger: ObjectName After Save

Turn Knowledge Into Action

We have been discussing about Salesforce best practices and design patterns in Salesforce Flow Design Patterns – from Fundamentals to Mastery – including in the current blog post. Now it’s time to put everything into a working model.

Here’s how to apply One Record-Triggered Flow Per Object framework in your org:

1. Create a SubFlow: Account Handler, which we will call from Record-Triggered flow when required.
   1. Use Record variables to pass Current and Prior Account records details:
      1. varR_NewAccount
      2. varR_OldAccount
   2. Use Boolean variables to isolate the logic for create or update event.
      1. varB_IsAfterInsert
      2. varB_IsAfterUpdate
      3. varB_IsBeforeDelete
2. Create the following Record-Triggered on a given object:
   1. Record-Trigger: Account Before Save
      1. Don’t support subflow
   2. Record-Trigger: Account Before Delete
      1. Call Account Handler Subflow
   3. Record-Trigger: Account After Save
      1. Call Account Handler Subflow
3. Then use more SubFlow to handle the business logic and call it form wherever required
   
   1. Subflow: Create Task
   2. Subflow: Post Account Creation

Subflow: Account Handler – Autolaunched Flow

First step is to create a SubFlow which is nothing but an Autolaunched Flow with the following variables. These variables will be used to store current and prior values of an Account’s record. It will also help us to identify the right decision nodes:

1. varR_NewAccount – Record variable
2. varR_OldAccount – Record variable
3. varB_IsAfterInsert – Boolean variable
4. varB_IsAfterUpdate – Boolean variable
5. varB_IsBeforeDelete – Boolean variable

varR_NewAccount

A Record variable is used to store current values of an Account’s record.

varR_OldAccount

A Record variable is used to store prior values of an Account’s record.

varB_IsAfterInsert

Boolean variable is used to store Flow context. We will pass the value to this variable from Record-Trigger: Account After Save.

varB_IsAfterUpdate

Boolean variable is used to store Flow context. We will pass the value to this variable from Record-Trigger: Account After Save.

varB_BeforeDelete

Boolean variable is used to store Flow context. We will pass the value to this variable from Record-Trigger: Account Before Delete.

Decision Node

Now use the decision element to identify the right path when a Subflow is called by a Record Triggered Flow:

After Insert Node

After Update Node:-

Before Delete Node:-

SubFlow: Account Handler

In the end, a Subflow will look like the following screenshot:

Record-Trigger: Account After Save

Now we will create After Save Record-Triggered Flow and call Subflow: Account Handler from it. Make sure that you pass the right value to variables.

Record-Trigger: Account Before Delete

Now we will create Before Delete Record-Triggered Flow and call Subflow: Account Handler from it. Make sure that you pass the right value to variables.

Record-Trigger: Account Before Save

As of Winter’22 release, Salesforce Before-Save Flow did not support Subflows. Feel free to write all the logic in the same flow. Check out this article to understand when to use  before-save vs after-save Record-Triggered Flow.

What’s Next?

Learning via a use case, ofcourse!!

Business Requirement:- Elise Shelley, a Lead App Developer at Universal Containers (UC), receives a requirement to create a Task whenever a new Account gets created.

As you know, creating a Task is very common after a deal is won or lost. So, based on what we learnt above, let us create a SubFlow to create a Task:

SubFlow: Create Task:-

1. Create a Record Variable Task to store Task values
2. Then use Create Records element to create a new Task.

Map Task Variable:-

Next step is to open Subflow: Account Handler. Under node After Insert add an Assignment Element to map Task record variable.

Map Task Fields:-

Now add SubFlow to create a Task and pass {!varRTask_Insert} variable.

At the end, your Flow should look like the following screenshot:

Going forward, form an habit to modify Account Handler whenever you get a new requirment and don’t touch the main Flow i.e. (Record-Trigger: Account After Save and Record-Trigger: Account Before Delete).

Have your own Salesforce Flow secret sauce? Great! Share it!

Formative Assessment:

I want to hear from you!

Have you taken the User Experience Designer exam? Are you preparing for the exam now? Share your tips in the comments!

Make a post and tag me on Twitter @automationchamp using #AutomationChampionFlow.

Proofreader: - Munira Majmundar