After designing the data model for Skill Align, I moved to the next critical layer:
Who will use this system — and what should they see?
In Salesforce, defining users and access is just as important as defining objects.
Why I Created Three Users
Skill Align mirrors a real organization. So I created three users:
HR
Project Manager
Employee
Each represents a distinct business role with different responsibilities and levels of control.
HR – The Controller
HR is responsible for:
Creating Employee records
Managing Skills
Confirming allocations
HR requires full system-level access.
Since the Developer Org already provides a default System Administrator user, I used that to represent HR. This avoids consuming additional licenses while still maintaining complete administrative control.
Project Manager – The Decision Maker
Project Managers:
Create Project records
Define required skills
Review candidates
They do not need:
System configuration access
Administrative privileges
Unrestricted data visibility
Their access must remain business-focused and project-scoped.
Employee – The Contributor
Employees:
View their skills
Update confidence levels
View project assignments
They should not:
Allocate themselves
Modify other employees
Delete important records
Their access must be limited and self-contained.
License Limitation & Profile Strategy
Initially, I assigned both Project Manager and Employee to the Standard User profile.
However, I quickly realized something important.
Editing Standard User directly is not a clean architectural practice.
It is a generic baseline profile provided by Salesforce. Heavily modifying it can create maintenance complications later — especially as the org grows or additional use cases are introduced.
Instead of altering a shared foundation, I created a dedicated custom profile: Skill Align User
This profile became the controlled baseline for both Project Manager and Employee users.
(We will understand Profiles in detail shortly.)
Why create a new profile?
To isolate all project-specific configurations
To maintain clean and scalable architecture
To retain flexibility for future enhancements
The final structure became:
HR → System Administrator profile
Manager → Skill Align User profile
Employee → Skill Align User profile
Creating Three Separate Lightning Apps
To improve usability and simulate real enterprise structure, I created:
HR App
Manager App
Employee App
Each app contains only relevant tabs and objects.
What is a Tab?
A Tab in Salesforce is a navigation element that provides access to an object or feature.
For example:
Employee Tab → Opens Employee records
Project Tab → Opens Project records
Tabs determine what users can access within an app interface.
The Next Challenge
At this point, both Manager and Employee shared the same profile:
Skill Align User
If multiple apps are assigned at the profile level, both users would see all assigned apps.
That defeats role-based separation.
The architectural question then became:
How do I differentiate access without creating multiple similar profiles?
This is where understanding Profiles and Permission Sets becomes critical.
Profiles vs Permission Sets
Profile
A Profile:
Is mandatory (every user must have one)
Defines baseline permissions
Controls object access, field-level security, and app visibility
Think of a profile as the foundation of a building.
It should remain stable and minimal.
One user → One profile.
Permission Set
A Permission Set:
Is optional
Adds additional permissions
Can be assigned selectively
Think of it as a modular extension added to the foundation.
The base stays clean. Capabilities are extended only where required.
One user → Multiple Permission Sets (if needed).
The Final Solution
I kept the Skill Align User profile intentionally generic.
Then I created two Permission Sets:
Manager App Access
Employee App Access
Inside each Permission Set, I configured:
Lightning App assignment
Required object permissions
Then I assigned:
Manager Permission Set → Only to Project Manager
Employee Permission Set → Only to Employee
This allowed both users to share the same profile while still seeing completely different apps and access levels.
Why This Design Matters
This approach:
Avoids modifying Standard User
Prevents unnecessary profile duplication
Works within license constraints
Follows Salesforce security best practices
Enterprise-level Salesforce design prefers:
Minimal profiles
Maximum flexibility using Permission Sets
Top comments (0)