04.02.01 — Profiles vs Permission Sets: QA Perspective
Lesson goal
This lesson explains how Salesforce security layering really works and why QA must test effective permissions, not configuration in isolation.
After completing this lesson, you should be able to:
- understand the relationship between Profiles and Permission Sets
- identify common conflict and override scenarios
- design security test cases that behave consistently across environments
This lesson opens the Security Testing section of Module 4.
The problem: the ambiguous user
Salesforce security is layered.
Historically, the Profile was the primary tool for access control.
Today, Permission Sets and Permission Set Groups are the preferred way to grant granular, role-based access.
From a QA perspective, this creates a problem:
the same user may behave differently depending on how permissions are layered, even if the visible configuration looks correct.
Security tests may pass in one Sandbox and fail in production simply because:
- permissions were granted manually during testing
- layered logic was not validated
- the source of a permission was not documented
Understanding permission layering is mandatory to test security boundaries correctly.
Profiles as the baseline
Every Salesforce user has exactly one Profile.
The Profile defines the baseline access level.
From a QA perspective, Profiles are primarily used to test deny logic.
Profiles typically control:
- object-level CRUD permissions
- default apps and page layouts
- baseline field-level security
QA focus:
Verify what the user cannot do.
Example:
- The Profile allows Read access to the Contract object.
- Delete access is explicitly denied.
- Regardless of Permission Sets, the user must not be able to delete Contracts.
If this restriction is bypassed, the security model is broken.
Permission Sets as additive logic
Permission Sets are additive.
They grant additional permissions on top of the Profile baseline.
They are typically used for:
- task-specific access
- temporary project roles
- cross-functional privileges
From a QA perspective, Permission Sets are used to test grant logic.
Example:
- The Profile hides the Annual Revenue field.
- A Permission Set explicitly grants Read access to that field.
- After assigning the Permission Set, the field must become visible.
QA must verify that:
- permissions are granted when expected
- no additional, unintended access appears
Conflict resolution: effective permissions
In most cases, Salesforce applies the most permissive rule when permissions overlap.
Typical outcomes:
- hidden fields become visible when granted via Permission Set
- object permissions expand when added by Permission Sets
- Apex classes become executable when explicitly granted
However, not all settings follow this rule.
Areas such as:
- Apps
- Page Layouts
- Record Type availability
are often still controlled primarily by the Profile or require configuration in both places.
These exceptions are common sources of production issues and must be tested explicitly.
Permission Set Groups and modern orgs
In mature Salesforce orgs, access is managed using Permission Set Groups.
Permission Set Groups:
- bundle multiple Permission Sets
- represent real business roles
- are the actual unit of access assignment
QA focus:
- test the Permission Set Group, not individual Permission Sets
- verify that the group grants exactly the intended access
- ensure the principle of least privilege is preserved
Practical QA strategies
Test the source of permission
Security testing should always document where a permission comes from.
An access matrix should clearly state:
- which permissions come from the Profile
- which permissions come from Permission Sets or Groups
This allows QA to:
- diagnose failures quickly
- avoid false positives
- maintain consistency across environments
The “remove the Permission Set” test
One of the most valuable negative tests is removal.
Procedure:
- Assign the Permission Set Group.
- Verify access is granted.
- Remove the Permission Set Group.
Expected result:
Access must be immediately revoked.
If access remains, the permission source is unclear or misconfigured.
Summary
Salesforce security is not defined by Profiles or Permission Sets alone.
It is defined by effective permissions, calculated from multiple layers.
From a QA perspective:
- Profiles define the restrictive baseline
- Permission Sets and Groups add controlled privileges
- testing must validate both denial and grant paths
Only by testing effective permissions can QA ensure that access control behaves predictably and safely in real Salesforce projects.
What’s next
In the next lesson, we expand security testing further:
04.02.02 — CRUD Testing on Salesforce Objects