Automate This! — Narender Singh’s ‘Multiple Flows Per Object’ Flow Design Pattern

Welcome to another “Automate This!” In this live-streamed video series, we cover all things automation, from use cases and best practices to showcasing solutions built by #AwesomeAdmin Trailblazers like you. Automation allows you to remove manual tasks, drive efficiency, and eliminate friction and redundancy. In this episode, three community Flow experts showcase their record-triggered flow design pattern. This blog post covers the record-triggered flow Narender Singh discussed during the episode.

In this blog, we’ll explore the various advantages that the ‘Multiple flows per object’ design offers around different aspects like performance, efficiency, architecture, maintenance, etc., in process automation in Salesforce.

1. Better performance

The ‘multiple flows per object’ design is considered to be better performant by Salesforce. Entry criteria is supposedly faster than evaluating decision nodes. Another reason I think contributes to the performance is if you have one flow, all the variables in the flow will occupy space in the memory for the entire flow transaction. Additionally, if you have formula variables in your flow, it’ll further negatively impact the performance because formula variables are reevaluated after every element. On the other hand, having multiple (smaller) flows limits the scope of variables to just the specific flow.

For ‘one flow (per context) per object’ design, we can use subflows to optimize after-save flows* to some extent, but subflows are not available for before-save flows.*

*Before-save flows are the flows configured as “Fast Field Updates”, and after-save flows are the ones configured as “Actions and Related Records”. Check out the Resources section to understand more about before-save and after-save flows.

2. Highly efficient

In the ‘multiple flows per object’ design, for every update on the record, only the flows that fulfills the entry conditions are executed which makes this design pattern highly efficient.

Whereas in the ‘one flow (per context) per object’ design, the flow is executed for every update and goes on evaluating every decision node.

3. Architectural consistency

For smaller orgs, architecture may not be a super important part of the implementation, but it becomes increasingly important as the org grows. ‘Multiple flows per object’ design offers a better and consistent approach in contrast to ‘one flow (per context) per object’ design because you can’t use subflows in before-save flows, which prevents you from adopting a modular approach all around.

4. Working with larger teams

The ‘one flow (per context) per object’ design, specifically for before-save flows, becomes problematic especially if you have a team of multiple admins. Admins can’t work on the flow simultaneously. As a result, the ‘one flow’ design will impact your ability to add new automation logic for multiple feature requests for an object.

However, for the ‘multiple flows per object’ design approach, this is not an issue.

5. Efficient maintenance

‘One flow (per context) per object’ design

Let’s imagine an org that has adopted the ‘one flow (per context) per object’ design. The admin has to implement several change requests. Per the requests, the admin needs to reorder the logic implemented in two flows, one before-save flow and one after-save flow. So, let’s see how the process of editing the flow could look like.

Before-save Flow Change Request

After-save Flow Change Request

As you can see, there are quite a few steps involved to reorder the elements and logic. And it’s still not done yet. The admin still has to test the logic and then deploy both flows.

‘Multiple flows per object’ design

Now let’s imagine the admin had to implement same change requests in an org that follows the ‘multiple flows per object’ design. In this case, all the admin needs to do is go to Flow Explorer and reorder the flow simply by dragging, as each piece of logic is implemented as a separate flow.

Overall, for the ‘multiple flows per object’ design, making changes is relatively easier and, additionally, it’s easier to isolate the changes to a specific flow especially when it comes to before-save flows.

Note: As a best practice, all the changes should be tested in a sandbox first before making changes in production.

6. DevOps friendly

Going through the flow changes in CI/CD** setup is not easy to visualize because you’re essentially reading an XML file. The ‘multiple flows per object’ design gives you more control to isolate the changes to specific flows which makes reviewing changes “relatively” easier. Not ideal, I know, but still better than reviewing changes in a 500-line XML file.

**CI and CD stand for continuous integration and continuous delivery/continuous deployment. In very simple terms, it’s a set of modern software development practices to automate building, testing, and deployment of applications.

7. Easier testing

With the ‘Multiple flows per object’ design, you can create smaller and isolated (as in one flow only handles one automation logic) flows. This helps in testing each flow in isolation. If you have developers writing Apex tests for flows, then it’s easier for them to write small and easy modular tests for each flow as opposed to writing tests for one giant flow (for example, for a before-save flow).

Give it a try

I hope this gives you a good overview of how you can benefit by using the ‘multiple flows per object’ design. Give this a try in your orgs and share with us your learnings and findings.

Resources

• External Site: ForcePanda: Why Before Save Flows Are 10x Faster than Process Builder
• External Site: Wikipedia: CI/CD
• Salesforce Admins Blog: Automate This! — Designing Record-Triggered Flows