Flow is how you automate things in Salesforce. Problem: anything over 10 seconds gets killed.
A client’s RevOps engineer spent three hours debugging last week. Her automation worked perfectly in testing. Then she turned it on for 2,000 records and it died.
The error: CPU time limit exceeded.
She hit the wall Salesforce doesn’t advertise: 10 seconds of processing time, total, for any automation.
What Flow Is (And Why It Has Limits)
Salesforce Flow is Salesforce’s built-in automation builder. You use it to create rules like “when a lead comes in, assign it to a rep” or “when a deal closes, update the account record.”
The catch: Salesforce runs on shared servers. Your automations run alongside thousands of other companies’ automations. To keep one bad workflow from crashing everything, Salesforce puts hard caps on what any single automation can do:
| What’s Limited | The Cap | What It Means |
|---|---|---|
| Processing time | 10 seconds | Your automation can’t think for more than 10 seconds total |
| Database queries | 100 | You can only ask for data 100 times |
| Records touched | 50,000 | You can only look at 50,000 rows |
| Saves | 150 | You can only save changes 150 times |
These limits apply to everything your automation does combined. If you loop through 200 leads and save each one, that’s 200 saves. The limit is 150, so your automation crashes on lead #151 and every change rolls back like it never happened.
Why Flow Breaks When You Scale
Flow works fine for simple things. It breaks when your business grows because the tooling wasn’t built for complexity:
You can’t see what changed. There’s no version history. You can’t compare today’s automation to yesterday’s. If something breaks after a change, you’re clicking through screens trying to remember what it looked like before.
You can’t test automatically. You click “Debug,” run it once, and hope. There’s no way to write tests that run before you deploy.
Errors are cryptic. When something fails, you get a vague email. Then you dig through nested boxes trying to figure out which step hit the limit.
Limits stack up fast. If your automation loops through 200 leads and does 3 database queries for each one, that’s 600 queries. You hit the 100-query limit on lead #34.
| Lead # | Queries Used | Result |
|---|---|---|
| 1 | 3 | ✓ OK |
| 33 | 99 | ⚠️ Almost at limit |
| 34 | 102 | ❌ Crashed, everything rolled back |
The Fix: Move Logic Outside Salesforce
Teams that hit these limits regularly don’t fight them. They move their automation logic outside Salesforce entirely.
The pattern: Salesforce stores your data. External tools run your logic.
| Keep in Salesforce | Move Outside |
|---|---|
| Customer records | Business rules |
| Deal data | Complex workflows |
| The UI your reps use | Integrations with other tools |
External automation tools like n8n, Make, or Tray don’t have these limits. Your workflow runs until it’s done, whether that takes 10 seconds or 10 minutes. You can process 50,000 records without hitting arbitrary caps. (If you’re on Zapier and hitting limits too, see our migration guide.)
And you get things Flow doesn’t have:
- Version control — export your workflows, track changes, roll back if something breaks
- Real testing — write automated tests that run before you deploy
- No arbitrary limits — process what you need to process
How This Works Technically
Here’s the key insight: Flow limits and Salesforce API limits are different.
Flow limits apply to everything your automation does in one transaction. It all shares the same 10-second budget.
API limits apply per request. If you call Salesforce’s API 100 times from an external tool, each call gets its own fresh set of limits.
One client moved their lead routing from Flow to n8n. The Flow version hit CPU limits at 500 leads per day. The n8n version handles 15,000 with the same logic.
”But External Tools Cost Money”
Yes. Typically $50-500/month depending on volume.
But consider what you’re paying now:
- Admin time debugging cryptic failures
- Lost leads when automations silently break
- Engineer hours working around limits instead of building features
| Flow | External Tool | |
|---|---|---|
| Tool cost | Included | $50-500/mo |
| Debug time | High | Low |
| Failures | Silent | Visible |
| Flexibility | Limited | Unlimited |
Most teams find the math favors external tools within a few months.
What To Do If You’re Hitting Limits
- Accept that the limits won’t change. Salesforce has had these limits for years. They’re not going away.
- Find your problem Flows. Which automations break most often? Those are candidates to move.
- Start with one. Rebuild your most problematic Flow in an external tool. See how it goes.
- Think of Salesforce as a database. Keep your data there. Run your logic somewhere designed for logic.
The 10-second limit isn’t a bug. It’s Salesforce telling you that complex automation belongs somewhere else. But even external workflow tools have their own limitations. The deeper question: do you need workflows at all?
Skip the wiring altogether. OpenClaw handles lead routing, enrichment, and follow-ups — talks to Salesforce as a data layer, no Flow limits, no workflow maintenance. Compare hosting options.