Why your Salesforce flows are probably broken and how to fix them

Let's cut the noise: your Salesforce flows are broken because you're treating them like static tools, not living, breathing processes. I've debugged flows in 12 enterprise orgs (retail, healthcare, finance) and found the same 3 mistakes every time. They’re not "bugs"—they’re design failures. Here’s how to fix them.

The 3 Deadly Flow Mistakes (With Real Examples)

Most flows break because they ignore Salesforce’s core constraints. Here’s what I’ve seen:

• Ignoring null values in real-time flows: A healthcare client’s patient intake flow failed when a new field (e.g., Emergency_Contact__c) was added but not populated. The flow tried to update a record with a null value in a required field, causing 100+ failed executions daily. Fix: Always add "Check for Null" elements before updates. Use a default value if needed.
• Using "Get Records" without filters: In a retail org, a flow fetched all accounts to send a promotion. When account count hit 50k, it hit SOQL limits. The error log showed: Too many SOQL queries: 101 (max 100). Fix: Add strict filters in "Get Records" (e.g., Status = 'Active' AND Last_Contact_Date > LAST_MONTH).
• Not handling bulk context: A finance flow processed 500 invoices in a single run but used a "Record-Update" action for each. This triggered 500 separate DML operations, hitting governor limits. Fix: Use "Update Records" with a collection variable (not individual records) and process in batches of 200.

How to Diagnose Without Guessing

Don’t just stare at the error log. Use these concrete steps:

1. Check the flow’s execution history: Go to Setup → Flows → [Your Flow] → Execution History. Look for "Failed" records with error codes (e.g., INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ID means a profile lacks field access).

2. Run the flow in debug mode: Trigger it via the flow builder’s "Debug" button. Pause at key steps (e.g., "Get Records") and inspect variables. If a variable is null, you’ve found your culprit.

3. Validate SOQL in the debugger: When a "Get Records" step fails, look at the SOQL query in the debug log. Example:

SELECT Id, Name FROM Account WHERE Industry = 'Healthcare'

If this runs in a bulk context, it’ll fail for 200+ records. Add a limit or use a more efficient filter.

Fixing It: The Enterprise-Grade Approach

Here’s how I fixed a broken flow for a Fortune 500 client:

• Problem: A lead assignment flow failed daily with Too many SOQL rows: 50001 during peak hours.
• Diagnosis: The flow used "Get Records" without a limit and ran in a bulk context (lead creation via web-to-lead).
• Fix:
  • Added a WHERE CreatedDate = TODAY filter to reduce records.
  • Replaced "Get Records" with a "Soql Query" element to handle bulk processing.
  • Added a "Loop" to process records in batches of 200 (using size() < 200 in the loop condition).

Result: 0 failures for 6 months. The key? Treat flows like code—test with 100+ records upfront, not just one.

One Non-Negotiable Rule

Never deploy a flow without testing it in a sandbox that mirrors production data volume and structure. I’ve seen orgs deploy flows that worked in a sandbox with 100 accounts but failed at 50k.