How to Fix Salesforce Flow Overlap (Race Conditions)

282 automations stacked on the Opportunity object. 14 active Flows. 4 Apex Triggers. 18 Workflow Rules from 2019. Three race conditions detected on save. This is the median mid-market Salesforce org we audit, and the playbook below is how the highest-performing teams fix it.

What is flow overlap (race condition)?

A race condition occurs when two or more automations write the same field on the same record save trigger. The final value depends on which fires last, which Salesforce does not deterministically guarantee. Behavior is intermittent: works 95% of the time, breaks 5% of the time, nobody can reproduce on demand.

The four most common race condition patterns:

1. Flow + Trigger writing same field. Both run after save. Order is undefined.
2. Workflow Rule + Flow writing same field. WR runs after Flow, often overwriting the Flow value.
3. Multiple Flows on same object with overlapping field targets. Order determined by API name alphabetically, fragile.
4. Trigger calling another Trigger via record update. Recursive depth (max 16) trips silently.

The 5-stage playbook

Stage 1: Detect (Day 1, 90 minutes)

Run the free Salesforce Flow Audit or manually inventory automations per object.

Manual inventory steps:

1. List all active Flows per object. Setup > Process Automation > Flows. Filter by triggering object.
2. List all active Triggers per object. Setup > Object Manager > [Object] > Triggers.
3. List all active Workflow Rules per object. Setup > Process Automation > Workflow Rules.
4. List all active Validation Rules per object. Setup > Object Manager > [Object] > Validation Rules.

For each object, count total active automations. Flag any object above 25 automations as a high-risk candidate for race conditions.

Stage 2: Map field-write overlap (Day 1, 60 minutes)

For each automation on a high-risk object, identify the fields it writes. The Audit does this automatically by parsing Flow metadata and Apex source. Manually:

1. For each Flow: Open the Flow Builder. Note every Assignment element target field and every Update Records element field set.
2. For each Trigger: Read the Apex source. Note every record.Field__c = value assignment.
3. For each Workflow Rule: Setup > Workflow Rules > [Rule] > Field Updates. Note every field updated.

Build a matrix: rows = fields on the object, columns = automations that write to them. Any field written by 2+ automations is a race condition candidate.

Stage 3: Triage by impact (Day 2, 60 minutes)

Not all race conditions are equal. Triage by:

1. How often the records flow through. A race condition on Opportunity.StageName fires on every deal save. Critical.
2. Whether the field is reported on. A race condition on a field used in forecast reports is high-impact.
3. Whether the field is referenced downstream. Used in routing logic, validation rules, or integration logic = high-impact.
4. Whether the field is agent-touched. AI agents reading this field will see inconsistent values.

Build a prioritized list: top 5 race conditions to fix first, next 10 to fix in sprint 2, remainder to defer.

Stage 4: Consolidate (Days 3-5, 8-16 hours)

For each high-priority race condition, choose a consolidation pattern:

Pattern A: Single Flow, retire others. If two Flows write the same field, merge their logic into one Flow with explicit decision branching. Retire the second Flow.

Pattern B: One-trigger framework. If multiple Triggers exist on the same object, refactor to a single Trigger that dispatches to handler classes. This is the canonical Salesforce best practice and eliminates the Trigger-vs-Trigger race entirely.

// One-trigger framework example
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);
    }
}

Pattern C: Retire legacy Workflow Rules. Salesforce deprecated Workflow Rules in Spring 2024 with phased removal through 2025. Every active WR should be migrated to Flow. Map: WR Field Update -> Flow Assignment element + Update Records element.

Pattern D: Move Flow logic into the Before Save context where possible. Before-Save Flows are faster and avoid the race entirely (they modify the record before it commits).

Stage 5: Validate and ship (Days 6-7, 4-8 hours)

For each consolidated automation:

1. Deploy to sandbox first. Run the Modern Deploy or use Change Sets if you must.
2. Run regression tests. Apex unit tests, plus manual UI walkthrough of the affected business process.
3. Compare before/after field values on test records. They should match the intended business logic.
4. Run the Flow Audit again. Confirm race condition count dropped to zero on the consolidated object.
5. Deploy to production via Modern Deploy with auto-snapshot rollback enabled.
6. Monitor for 7 days. Watch the affected report metrics for unexpected drift.

Common pitfalls

• Skipping Stage 2. Without the field-write matrix, you do not actually know what overlaps. Manual analysis here is critical.
• Consolidating before testing. Always sandbox first. Always run regression tests. Production-direct changes break things.
• Removing legacy Workflow Rules without verifying they replicated to Flow. The WR fires automatically; the Flow may not, if not configured identically.
• Refactoring multiple objects in parallel. Do one object at a time. Validate, then move to the next. Concurrent refactors compound the risk.

When to use the agent

The Clientell agent can automate stages 1-4 substantially:

• Stage 1 (Detect): Automatic via Flow Audit. 10-minute scan vs 90-minute manual.
• Stage 2 (Map): Automatic. The audit produces the field-write matrix from metadata.
• Stage 3 (Triage): Semi-automatic. The audit ranks by impact; you confirm the priority.
• Stage 4 (Consolidate): The agent generates the consolidated Flow draft and the one-trigger framework Apex. Human reviews and approves.
• Stage 5 (Validate and ship): Semi-automatic. Sandbox dry-run is automatic; production deploy requires your approval.

End-to-end with the agent: 1-2 weeks of admin time for a typical Opportunity object remediation. Manual: 4-6 weeks of focused architect time. Same outcome.

Related resources

• Salesforce Flow Audit — automated detection
• 15 Salesforce Flows Quietly Tanking Your Org — anti-pattern checklist
• Salesforce Technical Debt Audit — graders for Apex test coverage and code quality
• Modern Salesforce Deployments — ship consolidations safely with rollback
• How efficient Salesforce teams audit their org in 7 days — broader workflow playbook