Automation Chaos: Why Flows Break Even When Everything Looks Fine

Every Salesforce tester has experienced this moment:
A business user raises a ticket saying, “The system is broken.”
You open the record, click the same button…
And everything works perfectly.

Welcome to the wonderful world of Salesforce automation, where things break silently, inconsistently, and only when you’re not looking.

This is a story about one such moment — and why it taught me to never trust a Flow that “looks fine.”

The Case of the Polite, Well-Behaved Flow
During one project, we had a Flow that managed a relatively simple business process:
- update a few fields
- create a related record
- send a notification

Nothing exciting. Nothing dangerous. Nothing that should keep anyone awake at night.

And for weeks, it worked flawlessly.
UAT? Passed.
Regression? Passed.
Bug reported? Zero.

So when a defect appeared — “Flow doesn’t create the related record” — everyone assumed it was user error.

The consultant retested.
The developer retested.
The PM retested (yes, really).

All green.

The user tried again. Still broken.

When “sometimes” is the worst answer
Intermittent failures are the final boss of Salesforce QA.

If something fails every time — great, we’ll find it.
If something never fails — even better, we’ll ignore it.
But if something fails only on every third Thursday when Mercury is in retrograde, we enter chaos.

So we dug deeper.

We repeated the exact same scenario with two different test users:

• Admin → Flow worked
• Sales Rep → Flow sometimes worked, sometimes not

That’s when the truth started peeking out.

The culprit: “Required?” Yes. “Visible?” No.
Flows are obedient.
Flows do exactly what the system allows them to do.
Flows also do not care about your feelings.

A missing related record means one of five things:

• wrong profile permissions
• missing field access
• missing object access
• required field not populated
• or… the silent killer: FLS inconsistencies

And that’s what we found.

A field used inside the Flow was:

• Required at the database level,
  BUT
• Invisible for that Sales Rep

Meaning:
The Flow could try to save the record — but the system blocked the save because the user wasn’t allowed to see (or populate) the required field.

Error message?
Hidden in logs. Naturally.

Logically?
Perfectly Salesforce.

The Lesson: Always suspect what you cannot see
The problem wasn’t the Flow.
The Flow was perfect.
The permissions were not.

And that’s the heart of Salesforce QA:

Your real job is not testing logic.
Your real job is testing the permission model.

Flows are predictable.
Permissions are chaos.

This is why testers who focus only on “what SHOULD happen” miss half the bugs.
You must also test:

• what cannot happen,
• what must not happen,
• and what should happen only for specific people,
  because Salesforce is access-first, logic-second.

How to avoid this in your own projects
A simple checklist can save you from hours of staring at a Flow wondering if it hates you personally.

Before testing any automation, always check:

1. Does the user have access to every field used by the automation?
Especially hidden technical fields.

2. Does the user have CRUD access to every object the Flow touches?
No access → No magic.

3. Are required fields marked as visible AND editable?
Invisible = unfillable = failing save.

4. Does the automation run “with sharing” or “without sharing”?
Yes — this matters more than you think.

Automation doesn’t break randomly.
It breaks when permissions disagree with logic.

Final Thoughts:
Salesforce automation is rarely the source of chaos.
It’s just the messenger carrying bad news from the security model.

When a Flow works for Admins but not for end users, don’t debug the Flow.
Debug the access.

And remember:
If something breaks only “sometimes,” that is your sign that you’re dealing with access logic, not business logic.

If you enjoyed this story and want more real-life breakdowns of Salesforce QA challenges, stay tuned — we’re just getting started.