Salesforce Is Deterministic. People Are Not.

The Most Unfair Complaint in the Ecosystem

One of the most unfair things people say about Salesforce during a crisis is this:

“The system is behaving randomly.”

It’s the go-to excuse when a bug appears, disappears, and then reappears three days later. It comforts the team to believe that the platform is a black box of chaos.

But it isn’t. Salesforce is painfully deterministic.

People are not.

Salesforce Is Boring (In a Good Way)

At its core, Salesforce is a massive state machine. It is relentless. It is emotionless.

Given the exact same inputs—Data, Configuration, Permissions, Automation, and Execution Order—it will always produce the exact same output.

Every time. Without mercy. Without context.

If a result changed, it isn't because Salesforce "had a glitch." It is because something else changed first.

  • A timestamp shifted.
  • A user ID is different.
  • A related record is locked.
  • A cache refreshed.

Salesforce executes the aftermath of our decisions. It doesn’t improvise.

Humans Bring the Chaos

Projects feel unpredictable because humans are involved. We introduce the variables that break the deterministic model.

We cause the chaos when we:

  • Forget a decision made in a sprint six months ago.
  • Override a Validation Rule "temporarily" to load data and forget to turn it back on.
  • Test as a System Admin (bypassing the security model).
  • Deploy a Flow but forget the Custom Label it references.
  • Assume standard default values are harmless.

The code didn't change. The context did.

The QA Paradox

QA lives in a strange contradiction in the Salesforce world:

  1. The System is deterministic.
  2. The Inputs are chaotic.

Requirements shift mid-sprint. Data is inconsistent between Sandboxes. Users behave creatively in ways no User Story predicted.

QA’s job becomes less about testing and more about stabilizing reality. We are the ones who have to force the inputs to be consistent so we can prove the system's behavior.

"It Worked in UAT"

Of course it did.

"It worked in UAT" is usually an admission that the variables changed.

  • Different Users: UAT users often have broader permissions than Production users.
  • Different Data: UAT data is often clean; Production data is messy.
  • Different Timing: UAT happens in isolation; Production happens during high load.

You entered the same metadata into a different universe. Salesforce didn't betray you. Your assumptions about the environment did.

Debugging Without Drama

Once you accept that Salesforce is deterministic, your approach to debugging changes. You stop relying on luck and start relying on logic.

Instead of asking: "Why is this happening?"
You ask: "Under what exact conditions does this happen?"

When something "random" happens, it is usually one of these invisible factors:

  • Recursion: A Flow fired twice because of a related update.
  • Race Condition: An integration retried in the background while the user was editing.
  • Order of Execution: A Validation Rule ran after a workflow field update, catching a value you didn't see on screen.
  • Permission Drift: A Permission Set silently granted access via a Group you didn't check.

None of these are random. They are just invisible unless you know where to look.

Why QA Is Essential

Salesforce doesn’t protect you from complexity. It lets you build complexity faster than any other platform.

QA is the role that:

  • Slows things down just enough to verify the inputs.
  • Asks the boring questions about data state.
  • Maps cause to effect.
  • Restores determinism to the project.

Without strong QA, Salesforce projects don’t fail loudly with a crash. They drift. They slowly become unmanageable as the gap between "what we built" and "how it behaves" grows.

QA Takeaways

  1. Isolate the Variable: If a bug is "intermittent," find the one thing changing. Is it the user? The time of day? The record type?
  2. Trust the Logs: The Debug Log is the source of truth. If the log says it happened, it happened, even if the user says they "didn't touch anything."
  3. Standardize the Data: Never test with random data. Create a "Golden Dataset" that resets, so you can prove determinism.

Final Thought

Salesforce is predictable. Relentlessly so.

If something surprises you, it’s not because the platform is chaotic. It’s because someone—at some point—made a decision, and nobody remembered to test its consequences.

Deterministic systems don’t need intuition. They need clarity.

Subscribe to Salesforce Tester

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe