How to Detect Salesforce Flow Race Conditions (2026)

Editor's note: This guide draws on 1,000+ Salesforce flow audits we have run on production orgs. The pattern numbers (282 automations on Opportunity, 3 race conditions per critical object, 80% race condition prevalence) are median findings from that dataset.

TLDR

• A Salesforce race condition is two or more automations writing the same field on the same save trigger, with non-deterministic order.
• The pattern is invisible most of the time; it manifests as the 5% of records that have wrong field values nobody can reproduce.
• Detection requires building a field-write overlap matrix across all automation types: Flows, Apex Triggers, Workflow Rules, Validation Rules, Process Builder processes.
• The median 4-year-old mid-market Opportunity object has 282 stacked automations and 3 race conditions detected on first scan.
• Run the free Salesforce Flow Audit for automated detection, or follow the 4-step manual playbook below.

What a race condition actually looks like

Friday afternoon. Sarah on the data team reports that her quarterly forecast is off by 12 deals. Last quarter's number was different yesterday. She refreshes the report. The number changes again. By Monday morning the number is something else entirely.

The cause: two automations are writing to Opportunity.ForecastCategory on save. One is a Flow added by the previous admin in 2022. The other is an Apex trigger added during a CPQ implementation in 2024. They both fire after every save. Salesforce does not guarantee fire order between Flows and Triggers. The "final" value is whichever one happened to run last for that particular record save, which depends on internal Salesforce scheduling Sarah cannot see.

This is a race condition. It produces intermittent, irreproducible bugs that resist root cause analysis. The teams that find them tend to find them after they have already cost a quarter or a customer.

The four kinds of race conditions

1. Flow + Trigger on the same field. Both run after save. Order is undefined. Most common pattern in mid-market orgs.

2. Workflow Rule + Flow on the same field. Workflow Rules run after Flows by default but in some edge cases Flows re-trigger and re-fire. Inconsistent results.

3. Multiple Flows on the same object writing the same field. Order is determined by API name alphabetically, which is fragile. Renaming a Flow can change which one wins.

4. Trigger calling another Trigger via record update. Recursive depth (max 16) trips silently. The update propagates through multiple triggers, each potentially writing to fields the others depend on.

The 282-automation Opportunity object I mentioned has all four patterns at once. That is why these compound.

Why Salesforce does not warn you

Salesforce gives you each automation builder (Flow, Apex Trigger, Workflow Rule, Validation Rule) as a separate Setup surface. There is no consolidated "what writes to this field" view. There is no race condition detector. There is no "warn if two automations target the same field" check.

Each automation builder works correctly in isolation. The race condition is an emergent property of running multiple automation builders together. Salesforce treats this as a configuration choice you opt into, not a warning condition.

The result: you can build a perfectly correct Flow that breaks production when combined with a perfectly correct Trigger somebody else built. Both are correct individually. The combination is the bug.

The 4-step detection playbook

Step 1: Inventory automations per object

For each object you want to audit, list every active automation:

Flows on the object:

• Setup > Process Automation > Flows
• Filter by trigger object
• Note: record-triggered Flows are the highest-risk for race conditions

Apex Triggers on the object:

• Setup > Object Manager > [Object] > Triggers
• Count active triggers
• Note: one trigger per object is best practice; multiple triggers compound race risk

Workflow Rules on the object:

• Setup > Process Automation > Workflow Rules
• Filter by object
• Note: every active Workflow Rule in 2026 is technical debt (Salesforce deprecated them Spring 2024)

Validation Rules on the object:

• Setup > Object Manager > [Object] > Validation Rules
• These run on save; lower race risk but high cumulative impact

Process Builder processes:

• Setup > Process Automation > Process Builder
• Deprecated alongside Workflow Rules; same legacy status

The median 4-year-old Opportunity inventory: 14 Flows, 4 Apex Triggers, 18 Workflow Rules, 246 Validation Rules. The 282 total comes from this sum.

Step 2: Build the field-write matrix

For each automation, identify the fields it writes. Then build a matrix:

• Rows: every field on the object that any automation writes
• Columns: every automation
• Cells: whether that automation writes that field

Any row with 2+ filled cells is a race condition candidate.

How to extract field writes per automation type:

For each Flow:

1. Open the Flow Builder
2. Note every Assignment element target field
3. Note every Update Records element field set
4. Note every Create Records element field set on the same object

For each Apex Trigger:

1. Read the source
2. Grep for record.Field__c = and record.FieldName = patterns
3. Note all field assignments in before triggers (which become the saved value)
4. Note all field assignments in after triggers that update via SObject

For each Workflow Rule:

1. Setup > Workflow Rules > [Rule]
2. Note the Field Updates section
3. Each Field Update = a field write

For each Validation Rule:

1. Validation Rules only block save; they do not write fields directly
2. Exclude from the field-write matrix

The output is a spreadsheet. Conditional formatting on rows with 2+ filled cells. Race conditions in red.

Step 3: Triage by impact

Not all race conditions are equal. Triage by:

1. Save frequency. How often does this field write happen? Opportunity.StageName on every deal update: high frequency, high impact. Custom_Audit_Note__c on an admin-only update path: low frequency.

2. Downstream dependencies. Is the field reported on? Used in routing logic? Read by an integration? Used as a Flow trigger? Each dependency multiplies the impact.

3. Field type. Picklist races produce inconsistent enum values. Text races produce inconsistent strings. Number races produce wrong calculations. Date races produce wrong timestamps. All bad but in different ways.

4. Agent dependency. If you are deploying or planning Agentforce, automation overlap is the #1 AI killer. Any race condition on an agent-touched field is a critical pre-launch fix.

The top 5 race conditions get sprint priority. The next 10 get next sprint. The rest can be deferred until cluster cleanup.

Step 4: Consolidate

Four patterns for resolving race conditions:

Pattern A: Merge multiple Flows into one. If two Flows write the same field, combine their logic into one Flow with explicit decision branching. Retire the second.

Pattern B: One-trigger framework. Multiple Triggers on the same object refactor to a single Trigger that dispatches to handler classes:

trigger OpportunityTrigger on Opportunity (
    before insert, before update,
    after insert, after update
) {
    new OpportunityTriggerHandler().run();
}

public class OpportunityTriggerHandler extends TriggerHandler {
    public override void beforeUpdate() {
        OpportunityStageHandler.handle(Trigger.new, Trigger.oldMap);
        OpportunityRoutingHandler.handle(Trigger.new);
    }
}

Each handler runs in deterministic order. Race conditions eliminated.

Pattern C: Retire Workflow Rules. Every active Workflow Rule is technical debt. Map each WR field update to an equivalent Flow assignment. Migrate. Validate. Deactivate the WR.

Pattern D: Move to Before-Save context. Before-Save Flows execute before the record commits. They modify the record in memory. No after-save race possible with Triggers because the record already has the Before-Save value baked in.

For the 4-step playbook in operational detail, see How to Fix Salesforce Flow Overlap (the playbook).

Tools that detect race conditions

Manual detection works but is slow. Tools to accelerate:

1. Clientell Flow Audit (free). Reads the metadata graph, builds the field-write matrix automatically, surfaces race conditions per object with severity ranking. 10 minutes.

2. Salesforce Optimizer. Free Salesforce-native tool, surfaces some automation counts but no race condition detection.

3. Hubbl, Strongpoint, Salto. Paid governance platforms with overlap analysis. More expensive than Clientell, deeper governance features.

4. Manual via SOQL. You can query MetadataComponentDependency and FlowDefinition tables to build the matrix yourself if you have the patience. Most teams do not.

The cost of race conditions

Hidden until they bite, then expensive to root-cause:

• 5% intermittent data corruption. The records that show up wrong in reports, the deals routed to the wrong rep, the customer record that displays the right info one day and the wrong info the next.

• Compounding test failures. Apex tests pass individually but fail when the full test suite runs. The deploy gets blocked. The architect spends days isolating the cause.

• Failed Agentforce rollouts. Agents operate on the field values they see. If the values are non-deterministic, the agent's decisions are non-deterministic. The agent "hallucinates" because the data is unstable.

• Audit findings. SOC 2 CC7.2 (system monitoring) and CC8.1 (change management) both require deterministic system behavior. Race conditions are a finding waiting to happen.

The median cost we estimate per unresolved race condition on a critical object: $50K-$200K per year in lost productivity, wrong decisions, and intermittent customer impact.

How to prevent recurrence

Detection is half the problem. Prevention requires discipline:

1. One-trigger framework as an architectural standard. Codify it. New triggers go through the handler.

2. No new Workflow Rules. They are deprecated. Every new automation goes in Flow.

3. Before-Save Flows preferred over after-save where possible. Faster, no race risk.

4. Permission to deploy automation requires field-write declaration. Admin proposes the Flow, declares which fields it writes, the deploy review confirms no overlap with existing automation.

5. Continuous monitoring via Flow Audit. Detection drift detection.

The orgs that build these habits stop accumulating race conditions. The orgs that do not accumulate them faster than they can clean up.

What to do this week

1. Run the free Flow Audit. 10 minutes. Get the race condition count for your top 5 objects.

2. Triage the findings. Top 5 get sprint 1, next 10 get sprint 2.

3. Establish the one-trigger framework if you do not have it.

4. Set up Change Intelligence to alert when new automation is added to objects with existing overlap.

5. Brief the admin team on the playbook. Race condition prevention is a culture problem, not a tool problem.

FAQ

Q: How is a race condition different from a recursive trigger?

Recursive triggers happen when a trigger updates a record, which fires the trigger again, which updates the record, ad infinitum until governor limit. Race conditions happen between separate automations writing the same field. Different patterns, both bad, sometimes confused.

Q: Will moving to Before-Save Flow eliminate all race conditions?

No. Before-Save Flows eliminate the Flow-vs-Trigger race specifically. But if you have multiple Before-Save Flows writing the same field, you still have a race between them. The one-trigger framework + single Before-Save Flow per object is the cleanest pattern.

Q: Are Validation Rules subject to race conditions?

Validation Rules check conditions; they do not write fields. So they do not participate in field-write races. But Validation Rules CAN block legitimate updates if they fire out of order with field-writing automations. A separate but related class of issue.

Q: How long does cleanup take for a 282-automation Opportunity object?

For a typical mid-market org with race conditions on 2-3 core objects, the cleanup sprint is 1-2 weeks of admin time, much of it agent-automated. Most orgs we work with reduce 282 automations to 80-120 (a 50-60% reduction) with zero functional regression.

Q: Can I run the Flow Audit on a sandbox?

Yes. The audit needs a read-only OAuth connection. No writes during the scan. Sandbox-first is a good way to validate the audit before production scanning.

Q: Does this work for Salesforce Industries Cloud (Vlocity)?

Vlocity adds OmniScripts and DataRaptors as additional automation surfaces. The flow audit covers Salesforce-native automations; Vlocity-specific overlap is a roadmap item.