Salesforce Testing Is Not About Salesforce

The Quiet Lie in the Job Description

There is a quiet lie hiding inside many Salesforce projects. It sounds innocent. It sounds reasonable. It sounds professional.

“We need someone who knows Salesforce really well.”

Every time I hear that sentence, I know exactly what will happen next. The team will hire an expert who creates complex, perfect configurations that pass every unit test, yet the system will crumble in Production.

Why? Because Salesforce testing is not about Salesforce.

Salesforce Is the Easy Part

Salesforce is not complicated. It is large. It is wide. It has a lot of buttons.

But it is not complicated in the way people think.

The platform is predictable. Its rules are documented. Its limits are explicit (even if annoying). Its failures are usually deterministic.

The chaos does not come from the platform. The chaos comes from how people think about it.

When something breaks in a Salesforce project, the blame almost always goes to the tool:

• “Salesforce is behaving strangely.”
• “This is probably a platform bug.”
• “The API is just weird today.”

It rarely is.

What usually happened instead:

• Someone assumed a Flow would run only once per transaction.
• Someone forgot that permissions are layered and subtractive.
• Someone tested one record instead of two hundred.
• Someone trusted the UI instead of the data model.

Salesforce didn’t misbehave. Salesforce did exactly what it was told to do.

The QA Trap: Feature Thinking

A lot of Salesforce QA starts with features: Record Types, Validation Rules, Flows, Permission Sets.

And that’s fine—until it becomes the only lens.

Real defects don’t live inside features. They live between them.

Salesforce bugs are rarely "inside" a Flow. They are almost always at the seam:

• Between the Flow and the Validation Rule.
• Between the Profile and the Permission Set.
• Between Record ownership and the Sharing Rule.
• Between the Bulk Update and the Governor Limits.
• Between UI visibility and Field-Level Security.

If you only test the feature, you miss the friction where the feature meets the rest of the ecosystem.

Why Admin-Level Testing Is Fiction

This is why testing as a System Administrator feels so comfortable.

When you test as Admin:

• Everything works.
• Everything is visible.
• Nothing is blocked.
• No errors appear.

That’s not because the system is robust. That’s because Admin is immune to consequences.

Admin testing removes security boundaries, ownership constraints, sharing logic, and real user friction. It is not "optimistic testing." It is fiction.

Salesforce QA Is Systems Thinking

Good Salesforce QA doesn’t ask:

“Does this feature work?”

It asks:

• What assumptions does this logic make? (e.g., "The user is always in Sales.")
• What happens at scale? (e.g., "What if 500 records trigger this at once?")
• What happens when the user is restricted? (e.g., "What if they can't see the parent record?")
• What happens when automation overlaps? (e.g., "Does the Trigger fight the Flow?")
• What happens when something fails halfway? (e.g., "Does it roll back, or leave partial data?")

Salesforce is not a CRUD app. It is a state machine with memory, automation, and side effects. And state machines don’t fail loudly. They fail subtly.

The Irony of Expertise

Here is the funny part: The more "Salesforce knowledge" someone has, the easier it is for them to miss real problems.

Knowledge creates shortcuts:

• “I know how this usually works.”
• “This pattern is standard.”
• “I’ve seen this before.”

Salesforce QA is not about knowing the answers. It’s about not trusting them.

QA Takeaways

• Test the Seams: Don't just test the Flow. Test the Flow and the Validation Rule and the Sharing Rule together.
• Test the Restrictions: Testing functionality is easy. Testing lack of access is where the bugs are.
• Master the Side Effects: If you change a field, what else happens? Reporting, Integrations, History Tracking?
• Ignore the "Standard": Just because a feature is standard Salesforce functionality doesn't mean it plays nice with your custom logic.

If you want to test Salesforce properly, stop trying to master Salesforce.

Instead, master boundaries. Master assumptions. Master failure modes.

Salesforce will do the rest—reliably, consistently, and without mercy.

And when something breaks? It probably wasn’t Salesforce.