The Bug Wasn’t in the Logic. It Was in the Assumption.
The Three-Week Time Bomb
There is a specific kind of Salesforce bug that hates being found early.
It doesn’t show up in System Integration Testing (SIT).
It doesn’t appear in User Acceptance Testing (UAT).
It certainly doesn't crash during the stakeholder demo.
It appears three weeks after go-live, usually on a Friday, when a user touches a record in a slightly different way than anyone anticipated.
When the investigation finishes, the developer looks at the Flow or the Apex class and says:
“But the logic is correct.”
They are right. The logic was perfect. The assumption was wrong.
Salesforce Bugs Rarely Live in Code
In traditional software development, bugs often hide in complex algorithms or syntax errors.
In Salesforce, bugs hide in context. They live in the invisible assumptions we make while building:
- Who owns the record?
- Which Record Type is being used?
- Has the automation already run once before?
- What permission layer is silently modifying visibility?
Most Salesforce defects are not "wrong logic." They are correct logic executed in an untested context.
The Most Dangerous Assumption: “This User Will Never...”
The most expensive sentence in a design session is: "Oh, don't worry, the user will never do that."
I have seen these assumptions shatter more times than I can count:
- "This record will always be created by Sales." (Until Marketing imports 5,000 leads via API).
- "Only Admins will ever update this field." (Until a Process Builder updates it in the background).
- "This Flow runs only once." (Until a user edits the record twice in one minute).
All of these assumptions are false in Production. Not because users are malicious or "stupid"—but because Salesforce allows more paths than your design diagram shows.
The Hidden Multiplier: Layered Automation
The logic often breaks because of the "Chain of Execution" that nobody modeled explicitly.
Consider this classic disaster chain:
- Flow A runs on Create (Logic is correct).
- Flow B runs on Update (Logic is correct).
- Apex Trigger adjusts ownership based on territory (Logic is correct).
- Sharing Rules recalculate, changing visibility (Standard behavior).
- Flow A fires again because the ownership change counts as an update.
- Validation Rule triggers because the user no longer has permission to edit the record they just created.
Result: System.DmlException.
Every individual element "worked." The failure lived between them.
QA Mistake: Testing Features Instead of States
Many QA strategies fail because they focus on CRUD (Create, Read, Update, Delete).
- "Can I create a record?"
- "Can I edit the field?"
But Salesforce behaves like a State Machine, not a form.
What matters is not can I edit it, but:
- Which state is the record in?
- Which state transition is allowed?
- Is this transition irreversible?
- Does this transition trigger a cascading automation?
If you are testing features, you are testing the UI. If you are testing state changes, you are testing the system.
The Uncomfortable Truth
If your test cases look like this:
- “Create Opportunity”
- “Edit Opportunity”
- “Delete Opportunity”
You are not testing Salesforce. You are testing the database's ability to store data.
Real Salesforce bugs happen when:
- Records move between owners.
- Statuses lock and unlock.
- Permissions intersect with automation.
- Historical data interacts with new rules.
That is where the bugs live.
A Better QA Question
To find these bugs, we need to invert our thinking.
Instead of asking:
“Does this work?”
Ask:
“What assumption must remain true for this to keep working?”
And then, deliberately break that assumption.
- Assume the user is NOT from Sales.
- Assume the record was created 2 years ago.
- Assume the automation runs twice.
That is where the real bugs are waiting.
QA Takeaways
- Test the "Re-": Don't just test assignment. Test re-assignment. Don't just test processing. Test re-processing.
- Identify the Assumptions: During refinement, write down every "the user will never" statement. Turn them into test cases.
- Map the State: Don't just test inputs. Test the transition from Draft to Active and back to Draft.
What is the worst "assumption bug" you’ve ever found in Production? Share your story below.