Why this mattered:
During the Apex Property Operations project, I needed different user roles (Admin, Operations Manager, Field Operative, Finance User) to:
- Access the same object
- But see different UI experiences
- Without creating multiple profiles (since all non-admin users shared the same Salesforce Platform license)
Profiles alone couldn’t solve this — and page layouts definitely couldn’t.
This is where Custom Permissions + Dynamic Visibility became the right tool.
Constraint 1: Same profile, different access
All non-admin users were on the Standard Platform User profile due to Developer Org licensing.
That meant:
- I couldn’t vary UI access using profiles
- Page Layout assignment wasn’t granular enough
- Permission Sets controlled access, but not UI behaviour on their own
*Lightning App Builder cannot evaluate Permission Sets directly. It can only evaluate Standard Permissions, Custom Permissions, and User/Record context.
To introduce role-based UI behaviour without fragmenting profiles, I used Custom Permissions as a visibility switch.*
Constraint 2: Constraint: Profiles couldn’t differentiate UI under a shared license
I wanted:
- Field Operatives to see a simplified Service Task record
- Managers to see additional fields and related data
- Admins to see everything
But Lightning App Builder doesn’t let you say:
“Show this page to users with Permission Set X”
It only understands:
- Standard Permissions
- Custom Permissions
- User / Device / Record conditions
So the missing link was Custom Permissions.
What a Custom Permission actually is
A Custom Permission is:
A reusable boolean flag you can turn on for users — and then reference anywhere in Salesforce logic.
It doesn’t grant access by itself.
It simply answers the question:
“Does this user have permission to do/see this thing?”
That makes it perfect for:
- Apex (later on)
- Lightning Page visibility
- Flow decisions
- Validation rules
What I built (step by step)
1. Created a Custom Permission
Setup → Custom Permissions → New
Example:
- Label: View Field Operative Service Task Page
- API Name:
View_Field_Operative_Service_Task
This became my visibility switch.
2. Added the Custom Permission to a Permission Set
I created:
Field Operative Permission Set
Then:
- Permission Set → Custom Permissions
- Enabled the new custom permission
📌 Important insight
Permission Sets carry Custom Permissions — they don’t replace them.
3. Assigned the Permission Set to users
Assigned Field Operative Permission Set to:
- Field Operative user only
Now Salesforce could answer:
“Is this user a Field Operative?”
Without relying on profile, role, or license.
Using the Custom Permission in Lightining App Builder
This is where the magic happened 💫
4. Built multiple Lightning Record Pages (same object)
For the Service Task object, I created:
- A Field Operative record page
- A Manager/Admin record page
5. Controlled page visibility with Custom Permission
In Lightning App Builder:
- Selected the Field Operative page
- Clicked Set Component Visibility
- Chose:
- Filter Type → Permissions
- Permission → Custom Permission
View_Field_Operative_Service_Task = TRUE
Result:
- Only users with that Custom Permission saw this page
- Everyone else saw the default page
🎯 No profiles
🎯 No duplicate objects
🎯 Fully license-aware
STAR framing
Situation
Different operational users required distinct Lightning experiences while sharing the same profile and license.
Task
Deliver role-specific Lightning record pages without introducing profile sprawl or violating license constraints.
Action
Created a Custom Permission, assigned it via a Permission Set, and used it in Lightning App Builder visibility rules to dynamically control which record page users could see.
Result
Delivered a license-compliant, scalable UI model that supports role-based experiences without additional profiles or duplicated objects.