Configuration vs Code: Why Salesforce Testers Must Think in Layers
Why two features that look identical almost never behave the same.
Early in my Salesforce career, a developer once told me:
„Don’t worry, it works the same way whether it’s built in Flow or Apex.”
That sentence cost us three days of debugging.
Because in Salesforce, how something is built matters more than what it does.
Two features may look identical from the user’s perspective, yet behave completely differently for a tester.
When the same button behaves differently
Imagine two simple automations:
- Sales rep updates a field
- Another field is recalculated
- A notification is sent
Straightforward, right?
Except one team built it in Flow, and the other rewrote it in Apex during a refactor.
From the outside, identical.
Underneath? Two versions of reality.
A Flow runs with one security model.
Apex can run with sharing or without sharing — and that word changes everything.
In one environment, everything worked beautifully.
In another, half the team couldn’t save a record.
Why?
Because the Flow respected the user’s permissions.
The Apex version did not.
Same visible outcome.
Entirely different testing scope.
Salesforce testers don’t just test behaviour — they test implementation style
This is the part no one tells beginners:
Two requirements with the same acceptance criteria may require completely different tests depending on how they are built.
And that’s why in Salesforce QA you always ask:
“Is this configuration or code?”
Because configuration has limits.
Code has risks.
And both create different types of side effects.
Configuration (Admin-built features)
Flows, validation rules, page layouts, approval processes, assignment rules…
These tend to be:
- predictable,
- strongly bound by platform rules,
- easier to review without dev support,
- sensitive to sharing settings,
- dangerous when someone adds a “small” update without understanding the landscape.
Testers must think like analysts here:
- Who can trigger it?
- Should the actor even see the field?
- What happens if data is incomplete?
- Does automation create records users shouldn't be able to see?
This is the world where negative testing rules everything.
Code (Apex, triggers, classes)
Code is powerful — and power creates risk.
Apex can:
- ignore sharing settings
- update thousands of records at once
- execute recursively
- break silently without UI errors
- exceed governor limits
This is where testers become detectives.
A typical question:
“What happens if we add one more product to the Opportunity?”
Sometimes everything breaks.
Sometimes nothing happens.
Sometimes Salesforce simply refuses to execute.
Testing Apex means testing:
- limits
- performance
- edge cases
- interactions with Flows
- data volume
- user access
This is where your analysis skills grow the fastest.
Why this matters for testers
A good tester checks behaviour.
A Salesforce tester checks behaviour + constraints + architecture.
If you ignore how something is built, you miss:
- hidden test conditions
- access issues
- race conditions
- automation conflicts
- limit violations
- unexpected system context behaviour
This is exactly why Salesforce QA is not manual testing — it’s structured curiosity.
A simple takeaway
Next time you get a requirement, ask one question before anything else:
„Is this built by configuration or by code?”
If you know the answer, your entire test approach will either shrink or expand instantly.
This is the silent secret of efficient Salesforce QA.
If you want more entries like this, follow the next posts.
The next one will be: “Understanding Data, Sharing and Access — The Invisible Wall Every Tester Must Learn to See.”