3 Flow Design Patterns That Are Killing Your Org's Performance

Salesforce Flow is powerful, but poorly designed flows are the number one cause of CPU time limit exceptions and sluggish user experiences.

With the retirement of Workflow Rules and Process Builder, Flow is now the undisputed king of declarative automation. But with great power comes great responsibility. Many admins build flows like they built Process Builders, resulting in catastrophic performance issues.

Here are the three most common Flow anti-patterns we see in our diagnostics, and how to refactor them.

1. The DML in a Loop Anti-Pattern

Performing database operations (Create, Update, Delete) inside a loop is the fastest way to hit governor limits. If you update a record inside a loop that runs 150 times, you will hit the 150 DML statement limit and the transaction will fail.

2. Overusing Record-Triggered Flows

Having 15 different record-triggered flows on the Opportunity object creates unpredictable execution orders. When a record is saved, Salesforce has to evaluate all 15 flows, often causing recursive loops and CPU timeouts.

This is the exact same problem we had with Process Builder, just in a new UI.

3. Querying Unnecessary Data

Using 'Get Records' to pull all fields when you only need two, or failing to use proper filter criteria, wastes memory and slows down execution. Be precise with your queries.

If you only need the Account Name and Industry, do not select "Store all fields." Select "Choose fields and let Salesforce do the rest," and specify only the fields you need. This drastically reduces the heap size of your transaction.

The One-Flow-Per-Object Debate

While the strict "One Flow Per Object" rule is no longer mandated by Salesforce, a consolidated approach is still best practice. We recommend one Before-Save flow and one After-Save flow per object, utilizing Subflows to handle specific business logic. This guarantees execution order and makes debugging infinitely easier.