The Invisible Wall: Why Access Testing Is the Superpower of Salesforce QA Because half the bugs in Salesforce are not bugs — they are permissions.
If you want to see a Salesforce architect panic, show them a user who can suddenly see a field they shouldn’t.
If you want to see a tester panic, show them a bug report that makes no sense because it “works for Admin.”
Every Salesforce tester eventually learns:
Nothing breaks as often — or as quietly — as access.
“It works for me” — the most dangerous phrase in Salesforce
Developers test as Admin.
Consultants test as Admin.
Project managers test as Admin.
Clients test as themselves.
And testers?
Testers test as the right user.
And that changes everything.
An Opportunity updates correctly… unless you're using the Sales Intern profile.
A Flow executes… unless your role is two levels below the record owner.
A field appears… unless your permission set is missing one tiny checkbox hidden under five layers of UI.
Salesforce is a platform where 95% of problems appear only for specific actors.
That’s why the most powerful tool a Salesforce tester has is not Postman, not Salesforce Inspector, not Workbench.
It’s understanding the invisible wall of sharing and security.
Why access testing is hard (and fun)
The challenge is simple:
- every user sees something different
- every object behaves differently depending on access
- automation may run with or without sharing
- some errors never appear in UI — they just silently fail
- flows often assume access that does not exist
In traditional software, permissions are usually simple.
In Salesforce, permissions are half the system.
You are not just testing what the system does.
You are testing what the system refuses to do.
The three layers that matter most
1. Object Access
CRUD: Create, Read, Update, Delete.
The basics — and yet the source of constant trouble.
Great for quick eliminations:
- Can the user create the record?
- Can they edit the field?
- Can they delete anything?
2. Field-Level Security (FLS)
This is where 50% of bugs hide.
If a field is invisible, hidden, or read-only, everything breaks:
- Flows
- Apex
- Screen components
- Integrations
Salesforce does not care.
It simply fails silently and moves on.
3. Record Access & Sharing
Roles, OWDs, sharing rules, manual share, implicit sharing…
This is where the invisible wall becomes a maze.
The same record behaves differently depending on:
- who owns it
- who created it
- what object it belongs to
- where in the role hierarchy the user sits
A tester who understands sharing becomes unstoppable.
Why this is a tester’s superpower
Most people on a project understand processes.
Some understand automation.
Few understand access.
A tester who can explain why something fails only for specific users becomes the person everyone trusts.
You stop being “just a tester.”
You become the system analyst.
A simple test that saves hours
Whenever you test anything, do this first:
- Pick the correct test user
- Remove Admin rights
- Try to break access
If something works for Admin but not for the actor:
- congratulations, you’ve found the real scenario
- saved hours of debugging
- and probably rescued someone’s sprint review
Final thought
Salesforce testing is not about clicking buttons.
It’s about understanding who can even see the button — and why.
Master access.
Master Salesforce.
Next entry in the series:
“Automation Chaos: Why Flows Don’t Always Do What You Expect.”