The Big Picture: Flow Architecture and You

Today we’re going to spend some time talking about Flow Architecture. I was asked this week by one of my students:

“I noticed we are making a few flows per object so far and I was wondering since workflow rules, process builders are being migrated to flow builder and there are several that get made over time, what is a best practice to have how many flows working per object in Salesforce?”

This is an excellent question. If you’ve ever wondered about this yourself, then you have the makings of a great Salesforce Architect.

In short, it’s still a topic of open debate. Some in the industry think you should only have one record-triggered flow per object. 

I’m currently of the opposite view. 

I’ve read a few books about Software Architecture and one common framework mentioned across these books are the five SOLID architectural principles for Object-Oriented Programming. (You can read the wiki here).

Those principles are as follows:

1. Single Responsibility Principle
2. Open-Closed Principle
3. Lishkov Substitution Principle
4. Interface Segregation Principle
5. Dependency Inversion Principle

The one I want to focus on today is the Single-Responsibility principle.

To quote Robert C Martin (who wrote "the book" on Clean Architecture):

“In the context of the Single Responsibility Principle (SRP) we define a responsibility to be “a reason for change.” If you can think of more than one motive for changing a class, then that class has more than one responsibility.“

More generally: “THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.”

Now Robert Martin is talking about classes (which are coding structures). In this context we’ll substitute the word “class” for Flow. Flows are simply code in visual form. Restated, his quotes read:

“In the context of the Single Responsibility Principle (SRP) we define a responsibility to be “a reason for change.” If you can think of more than one motive for changing a flow, then that flow has more than one responsibility.“

“THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A FLOW TO CHANGE.”

Why would this be a good design principle?

Let’s invert the problem and think about what happens in the extreme opposite case - one flow per object.

With one flow per object, every piece of automation for an object must live in the same flow. If you want to add or change a business process, you now must risk introducing a bug to every other business process running on the same object.

This is a maintenance nightmare. It significantly lengthens development time for existing Admins. And onboarding new team members is more difficult (because they need to understand a large flow in order to make changes).

A step removed from that extreme case would be one record triggered flow with numerous subflows. Again, I think this is an inferior option for two reasons:

1. Numerous subflows introduce maintenance and version control problems
2. Salesforce provides us a way to manage order of execution in flow (whereas before it did not)
   
   

One problem of calling numerous subflows inside one record-triggered flow is that it’s still a maintenance challenge. 

To effectively make changes you’ll need to toggle between several different flows to evaluate order of execution, and possibly update several flows at once in order to make a desired change.

Additionally, version control becomes a serious problem. Let’s say two Admins are working on separate flows. Admin 1 builds a new flow, deploys it, and adds it as a subflow to the one big record triggered flow.

A day later, Admin 2 builds a new flow, deploys it, and also adds it as a subflow to the one big record triggered flow.

The following day, users report that changes made by Admin 1 are causing bugs, and so the flow needs to be temporarily deactivated. To take this action, Admin 1 must revert their changes by:

1. Creating a new flow version to include Admin 2’s work and not their own work
   
   OR
   
   
2. Revert to a previous flow version without Admin 1 or Admin 2’s work 

Ick. That decision can be managed when the changes are recent. But what happens when bugs are reported several days, weeks, or months later? 

How is the decision handled when several other flow versions have been created in the interim? It just feels messy.

The Single Responsibility Principle simplifies all of this by separating each flow so that it’s responsible for one thing, and one thing only. We can activate, deactivate, and alter a flow in isolation from all the other flows. This is no minor benefit.

But how do we manage the execution order? The solution is in two new tools provided by Salesforce. 

• Flow Trigger Explorer
• Trigger Order

Flow Trigger Explorer lets us view all the flows running on a specific object, and shows us in what order and context the flow is running.

Flow Trigger order lets us specify in which sequence flows should run.

These are powerful tools that alleviate all the headaches described above. Now, we can create one single flow per business process and - if needed - specify which order to run it in. 

Neat.

When it comes to Process Builder or Workflow rule migration how do the principles in this discussion apply?

My take is that for the purposes of migrating off Process Builder it can make sense to group everything in one flow. I would argue that if you can take the time to break it out into separate flows that it's worth the effort. 

Over time if the flow is too complex or requires way too many changes then breaking it apart into separate flows will be worthwhile. Each process builder migration will be a judgment call for the Salesforce Admin or Dev doing the migration.

And that's it!

Today we covered:

• The five SOLID Architecture Principles
• How to Apply the Single Responsibility Principle to Flows
• Understood the benefits the SRP brings
• Discussed the benefits of using Flow Trigger Explorer and Execution Order
• Applied these concepts to Process Builder migration

PS - I found this article for Salesforce Architects and Takeaway #5 supports my line of thinking:

https://architect.salesforce.com/design/decision-guides/trigger-automation/

See you again next week!