With Workflow Rules and Process Builder retired, Flow is the undisputed king of declarative automation in Salesforce. But with great power comes the ability to completely tank your org's performance. We audit dozens of orgs a year and see the same five anti-patterns over and over. Here is how to identify them and the scalable patterns to replace them.
This is the single most common Flow performance killer we see. A record-triggered Flow loops through a collection of child records and fires a Get Records element inside the loop — one SOQL query per iteration. Hit 101 records and your transaction fails with a governor limit error.
The FixQuery all related records before the loop using a single Get Records element, then filter and reference the collection inside the loop. One SOQL query, regardless of collection size.
Flow A updates a field on Account. That update triggers Flow B, which updates a field on Account. That update triggers Flow A again. You now have an infinite loop that will either hit a recursion limit or silently corrupt data. We have seen this cause production outages.
The FixUse entry conditions rigorously. Add a condition that checks whether the field your Flow updates has actually changed before running. Use a custom metadata flag or a dedicated boolean field to prevent re-entry when the Flow itself is the source of the triggering change.
A single record-triggered Flow that handles 12 different business processes, has 50+ elements, and is impossible to debug or maintain. We call these "spaghetti flows." They are a maintenance nightmare and a performance risk — every record save triggers the entire flow regardless of which condition applies.
The FixDecompose into focused, single-purpose Flows. Use subflows to encapsulate reusable logic. Each Flow should do one thing and do it well. This also makes debugging dramatically easier — you can isolate and test each piece independently.
A Flow that calls an external system, sends an email, or performs a DML operation with no fault path is a silent failure waiting to happen. When the external call times out or the DML fails, the Flow throws an unhandled exception — and depending on your org settings, this can roll back the entire transaction or send an ugly error email to your admin.
The FixEvery element that can fail needs a fault connector. Route faults to a dedicated fault handler subflow that logs the error to a custom object, sends an alert to the right team, and — where appropriate — allows the original transaction to complete. Never let a fault silently swallow data.
Record Type IDs, Queue IDs, Profile IDs, and static values hardcoded directly into Flow elements. These break the moment you deploy to a new sandbox, migrate to a new org, or someone changes a record type name. We have seen entire deployment pipelines fail because of a single hardcoded Queue ID.
The FixUse Custom Metadata Types or Custom Labels to store environment-specific values. Reference them dynamically in your Flow. This makes your automation portable, testable, and environment-agnostic.
These five patterns are symptoms of the same root cause: Flow was built fast, by someone who understood the business logic but not the platform constraints. This is not a criticism — it is the reality of how most orgs grow. The fix is not to rebuild everything at once; it is to establish standards, do a targeted audit of your highest-traffic Flows, and address the critical risks first.
If your org is experiencing unexplained errors, slow page loads after record saves, or mysterious data inconsistencies, there is a good chance one of these patterns is the culprit.
Cleaning up technical debt is a heavy lift. If your team is stretched thin and you are not quite ready for a dedicated consulting partner, platforms like RevKit.ai can help optimize your existing revenue operations while you plan your cleanup.
We specialize in untangling complex automations and building for scale. Book a discovery call to discuss an org audit, or get an instant quote to scope your cleanup project.