The Ticket That Wasn’t a Bug (But Cost 6 Hours Anyway)
Some bugs are loud.
Some bugs are dramatic.
And some bugs… never existed in the first place — but still consume half your day, three people’s sanity, and the last bit of trust the business has in the system.
This is a story about the third type.
The Defect That Looked Too Simple
A user reported the following issue:
“The system doesn’t send the onboarding email after creating a new Customer record.”
Classic.
Automation fails → user panics → PM escalates → tester enters battlefield.
I opened the record.
Clicked the button.
Email sent.
No error.
Everything green.
So I retested with another user.
Worked again.
I politely replied: “Cannot reproduce.”
Five minutes later, a message arrives:
“Still broken.”
Here we go.
The Real Problem: The Data Was Wrong (But No One Saw It)
After a call with the user, something became clear:
They were not following the steps we assumed.
They were following the steps they believed were correct.
Their process:
- Create Customer
- Fill only the mandatory fields
- Save
- Expect email to be sent
- Panic when it isn’t
The Flow responsible for sending the email had a condition:
Industry != null
AND
CustomerSegmentc != null
Both fields were optional in the UI.
Both were empty in the user’s test.
The Flow wasn’t broken.
The data was.
The only defect was the assumption that users would read field labels.
Why This Cost 6 Hours?
Because every person checked the wrong thing first.
- Tester: “Automation works on my data.”
- Consultant: “Logic looks fine.”
- Developer: “Flow executed successfully in debug mode.”
- PM: “User insists it’s not working.”
The missing step was the most boring one:
✔ Compare user input vs expected input
✖ Assume user input is correct
It’s never correct.
Never.
The Lesson: Data Issues Are the Most Expensive “Non-Bugs” in Salesforce
Here’s the uncomfortable truth:
30–50% of all reported Salesforce defects are not defects.
They are data issues.
Bad test data.
Incomplete data.
Incorrect data.
Fields filled in the wrong order.
Fields filled with the wrong values.
Mandatory-for-logic fields that are not mandatory in the UI.
Salesforce is extremely sensitive to data shape.
Flows break silently.
Apex throws global errors.
Emails don’t send.
Automation doesn’t fire.
And all of this happens without a single red message on the screen.
What You Should Do Before Declaring Something a Bug
A simple three-step rule can save entire hours:
1. Recreate the user’s EXACT data
Not your “nice and clean” version.
Their chaotic one.
2. Review every field the automation depends on
Even invisible ones.
Especially invisible ones.
3. Test the negative path ON PURPOSE
Ask yourself:
“What happens if a user does the absolute minimum?”
The answer is usually:
“Everything breaks.”
Final Thoughts
The system wasn’t wrong.
The Flow wasn’t wrong.
The user wasn’t wrong either.
The process was wrong.
This is why Salesforce QA is not about finding defects.
It’s about understanding how people actually use the system—not how the system expects to be used.
And once you accept that users will never read the field labels…
Testing becomes much easier.
If you like stories from the frontline of Salesforce projects, more are coming — and some get even messier.