Why fine-grained permissions matter
CF
Chris Fenwick · CFO
"Our Finance team needs to see contract values on every Opportunity for revenue recognition. Our SDRs — who just qualify leads — absolutely should not see that number. I don't want to rely on people just 'not looking.'"
Relying on trust or training to keep sensitive data private doesn't scale and doesn't survive an audit. Access needs to be enforced by the system itself, consistently, everywhere the data could appear.
Business outcome
Sensitive fields are hidden consistently everywhere — record pages, reports, and the API — and access changes are a config change, not a code change.Anatomy of the two-tier model
Every user has exactly one mandatory Profile — the baseline. Permission Sets layer additional grants on top of that baseline, but they can only add access, never take it away.
| Layer | Controls | Can it restrict below the other layer? |
|---|---|---|
| Profile | Object CRUD, field-level read/edit, app access, tab visibility, system flags | N/A — this is the baseline |
| Permission Set | Extra grants layered on top for specific users | No — additive only, can never remove a Profile's access |
Key Profile flags to know:
| Flag | Effect |
|---|---|
isSystemAdmin | Full unrestricted access — bypasses every other check |
canViewAllData / canModifyAllData | See or edit every org record regardless of ownership |
canCustomizeApplication | Manage objects, fields, layouts, and apps |
marketingAccess | Unlocks Marketing Studio routes |
ADMIN role is special
A user with role ADMIN bypasses profile checks entirely, regardless of what their assigned Profile says — useful for platform operators, but assign it sparingly.Hide a sensitive field from one profile
Create the profileSetup → Profiles → New Profile — name it "Standard Sales User" (or clone an existing one).
Set object permissionsGrant Read/Create/Edit on Opportunity — deny Delete.
Hide a fieldOpen Field Permissions → find
contract_value__c (or any sensitive custom field) → uncheck "Can Read" for this profile.Assign itAttach the profile to a test user, then log in as that user.
VerifyOpen an Opportunity as that user — the hidden field should not appear anywhere on the record page.
Try a Permission Set
Create a Permission Set that grants Delete on Opportunity, and attach it only to your team lead — notice it adds the extra capability without needing a second profile.Test what you learned
1. Can a Permission Set remove access that a user's Profile already grants?
Yes, permission sets can restrict below the profile
No — permission sets can only add access, never remove it
2. Which flag gives a profile completely unrestricted access to everything?
canViewSetupisSystemAdminmarketingAccess