Salesforce Simplified: One Flow Per Object Strategy

Introduction

Salesforce we should create one record-triggered flow per object per type/event or context. This idea comes from the Apex trigger framework. As we can create multiple record trigger flows, but it will be difficult to manage those multiple flows. Better we can create two trigger flows for each object, one before the save operation and one after the save operation. In those before and after trigger flows, we can create decision elements and based on decision results we can call subflows.

What Are Salesforce Flows?

Salesforce Flows are a type of automation tool that allow users to create custom workflows and automate tasks without writing code. They enable the automation of complex business processes by using a visual interface to design and manage these processes.

The One Flow Per Object Principle

The ‘One Flow Per Object’ principle advocates for creating a single Flow for each Salesforce object, rather than having multiple Flows that handle different aspects of the same object. This approach offers several advantages:

1. Enhanced Clarity:

When you adhere to the One Flow Per Object principle, each Flow has a clear and specific purpose. This makes it easier for users and administrators to understand the functionality of each Flow, reducing confusion and making maintenance simpler.

2. Simplified Debugging:

With only one Flow per object, troubleshooting issues becomes more straightforward. If something goes wrong, you only need to inspect a single Flow, rather than sifting through multiple Flows that may impact the same object. This streamlined approach helps in identifying and resolving issues more efficiently.

3. Improved Performance:

Having a single, well-structured Flow per object can enhance performance by avoiding the complexity of multiple Flows interacting with the same object. This can lead to faster processing times and a more responsive Salesforce environment.

4. Easier Maintenance:

Maintaining and updating Flows is less cumbersome when there is a clear separation of concerns. If business processes change or new requirements arise, updating a single Flow per object is typically simpler than modifying multiple Flows that handle different aspects of the same object.

Flows Per Object Limits

We can create multiple flows on one object but This is complicated when organizations make a big flow that’s supposed to handle everything. You’ve got to perform regression testing on the entire flow after every single update, creating more technical debt. 

It is not possible in a large amount of complex logic used in flow to create just one record-triggered flow per object – you may have several actions that need to be executed before the database is updated and others that need to be run after. Your record-triggered flows can only run in one of the two contexts, so you may need to create a before flow and an after flow to satisfy your business needs.

Suppose record-triggered flows can be triggered either on Create, Update, Create or Update, OR Delete. You can configure your before and after flows to be executed on Create or Update, but Delete will need to be handled separately, etc

Flow Trigger Order

• Flows with the same trigger (before-save or after-save) on the same object with trigger order values from 1 to 1,000 run in ascending order. Multiple flows with the same trigger order value run in alphabetical order based on the flows’ API name.
• Flows without trigger order values run next and in the order of their created dates. Flows in Winter ’22 and before run and continue
  to run in this order, unless you define a trigger order value for them.
• Flows with trigger order values from 1,001 to 2,000 run next and in ascending order. Any ties are settled using the flows’ API names.

Advantage of one record-triggered flow per object

• Creating one Flow per object will enable create reusable Flows and manage all your Flows for a given object in one place.
• When you have just one Flow per object per type, You may hit governor limits – such as the number of SOQL queries; furthermore,
• Adding one Flow per object rule will also allow you to avoid generating infinite loops.
• 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.

Disadvantage of one record-triggered flow per object

• There is a possibility of running into a 2000 elements executed limit as your flow grows.
• Having one flow also consumes more memory since all the variables you create in the flow, live throughout the flow transaction.
• Doesn’t go well if you’ve multiple admins on the team.

Best practices for implementing one flow per object

1. Define Clear Objectives: Before creating a Flow, outline the specific business process it needs to automate. This clarity will help in designing a Flow that effectively addresses the requirements.
2. Use Subflows: For complex processes, consider using Subflows to keep the main Flow focused and manageable. Subflows can handle specific tasks or subprocesses, maintaining the overall structure of a single Flow per object.
3. Document Your Flows: Keep detailed documentation of each Flow’s purpose, logic, and any dependencies. This documentation will be invaluable for future troubleshooting and updates.
4. Test Thoroughly: Always test your Flows in a sandbox environment before deploying them to production. This ensures that they function as expected and do not introduce unintended side effects.
5. Monitor and Optimize: Regularly review the performance of your Flows and make optimizations as needed. Salesforce provides tools for monitoring Flow performance, which can help identify areas for improvement.

Summary 

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 the Naming convention so that the same flow can be reused. 

Adopting the ‘One Flow Per Object’ principle can greatly enhance the clarity and efficiency of your Salesforce instance. By keeping each Flow focused on a single object, you simplify maintenance, improve performance, and make troubleshooting more manageable. As Salesforce continues to evolve, leveraging best practices like this can help you stay ahead and ensure that your Salesforce environment remains robust and effective.