Building Skill Align – Part 3: Users, Apps, Profiles & Permission Sets

Source: Dev.to

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, each representing 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. Editing the Standard User directly is not a clean architectural practice; it is a generic baseline profile provided by Salesforce, and 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

Final structure

• 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, defeating 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 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

• 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