Building Skill Align – Part 5: Field-Level Security, Page Strategy & Lightning Pages
Source: Dev.to
Record‑Level Governance Recap
After establishing record‑level governance in Skill Align, I turned my focus to deeper system control.
Not just: Who can see records.
But:
- Who can influence a record’s lifecycle
- Who can modify its state
- Who can shape the operational flow
Today’s Focus
- Field‑Level Security (FLS)
- Page Layout Strategy
- Lightning Record Page Architecture
- Related List Governance
Object Governance Model
Each object in Skill Align serves a deliberate architectural purpose.
Catalog Objects – Stable Reference Data
These define standardized reference information used across the system.
| Object | Purpose | OWD | Editable By |
|---|---|---|---|
| Skill | • Define approved skills • Support matching logic and reporting • Remain stable over time | Public Read‑Only | Managers only |
Catalog stability ensures reporting consistency and matching accuracy.
State Objects – Represent Business Definition State
State objects define structured requirements or capability conditions.
| Object | Description | OWD | Owner |
|---|---|---|---|
| Employee Skill | Recorded capability currently held | Private | Employee |
| Project Skill Requirement | Capability required by a project | Private | Manager |
State objects define what is required or currently exists — not process transitions.
Transactional Objects – Represent Lifecycle Movement
These objects move through lifecycle stages and require controlled transitions.
| Object | OWD | Owner |
|---|---|---|
| Project | Private | Manager |
| Project Candidate | Private | Manager |
| Project Assignment | Private | Manager |
Ownership is not decorative metadata — it drives responsibility, visibility, and control.
Field‑Level Security : Lifecycle Authority
In Skill Align, FLS maps directly to lifecycle power—it determines who can alter system state.
Controlled Lifecycle Field
- Status (Project Assignment) – Editable only by Manager.
- Employees can view the assignment status but cannot modify it.
- This centralizes allocation authority and prevents lifecycle bypass.
Catalog Stability Control (Skill object)
- Editable only by Managers.
- Employees cannot redefine skill definitions.
Catalog consistency protects:
- Matching accuracy
- Reporting integrity
- System trust
Page Layout Strategy
What Is a Page Layout?
- Defines which fields appear in the Record Detail section
- Determines which Related Lists are displayed
- Controls standard/custom buttons that are available
- Provides basic section grouping
Note: Page Layout does not enforce security.
Security is enforced by OWD, Role Hierarchy, Permission Sets, and FLS.
Page Layout provides structural consistency—not access control.
Page Layout Architecture by Object
| Object Type | Object Name | Layout Strategy | Rationale |
|---|---|---|---|
| Catalog | Skill | Single Layout | Stable reference data |
| State | Employee Skill | Single Layout | Governance via FLS |
| State | Project Skill Requirement | Single Layout | Structured requirement definition |
| Transaction | Project Candidate | Manager‑only Layout | Employees have no access |
| Transaction | Project Assignment | Neutral Layout | Lifecycle control via FLS |
| Core | Employee | Single Layout | Persona differentiation via Lightning Page |
Layouts are intentionally minimal and consistent.
Why Page Layout Is Still Required (Even in Lightning)
What Is a Lightning Record Page?
A Lightning Record Page is built with Lightning App Builder and controls:
- Page structure (tabs, sections, columns)
- Component placement
- Conditional visibility
- App/Profile activation
It defines how the page is arranged.
Lightning Record Page vs. Page Layout
A common misconception is that Lightning replaces Page Layout. It does not.
- Page Layout → defines the field structure.
- Lightning Record Page → defines the page framework.
The Record Detail component pulls fields from the assigned Page Layout. Even if the Lightning page is redesigned visually, the structural baseline remains the Page Layout, so Page Layout stays foundational.
Dynamic Forms: Presentation Shift, Not Governance Shift
Dynamic Forms let fields be placed directly onto the Lightning Record Page, bypassing the Record Detail component.
When enabled:
- Field placement is controlled in Lightning App Builder.
- Page Layout no longer controls field positioning for that page.
However:
- Related Lists still depend on Page Layout (unless using Dynamic Related List).
- FLS continues to enforce edit access.
- Page Layout remains as a structural fallback.
Dynamic Forms shift presentation control—not governance control. Security still depends on FLS.
Activation Strategy: Assigning Lightning Record Pages
After designing a Lightning Record Page, activation determines who sees it. Salesforce provides three primary activation models.
1. Org Default
The page becomes the default for all users across the organization for that object.
Use when:
- Experience does not vary by persona.
- Structural consistency is required.
- Context specialization is unnecessary.
In Skill Align, Org Default activation is used for:
- Employee
- Skill
- Project
- Employee Skill
These objects remain stable and do not require contextual UI variation. Org Default ensures experience consistency across apps.
2. App Default
The page is activated only within a specific App. Users accessing the object from that App will see the assigned Lightning Record Page.
Use when:
- The same object behaves differently across Apps.
- Contextual experience is needed without altering governance.
- Responsibility differs by operational environment.
App Default activation is used for:
- Project Assignment
- Project Candidate
- Project Skill Requirement
These objects are responsibility‑sensitive and benefit from contextual interaction. App‑level activation enables UX specialization while preserving the same data model and security structure.
3. App + Profile (Granular Activation)
The most granular model. You can activate a page for:
- Specific App
- Specific Profile
- Optional Record Type
Use when:
- Persona‑based UI differences are essential.
- The same object must look different for different roles.
- Authority and responsibility significantly differ.
Note: This model is powerful—but must be used deliberately. Overusing profile‑based activation fragments user experience and complicates governance. Architecturally, it should be applied only when functional differentiation justifies it.
Related List Governance
Related Lists reinforce lifecycle clarity.
Employee displays
- Skills
- Project Assignments
Project displays
- Skill Requirements
- Candidates
- Assignments
Lifecycle flow becomes visible:
Skill Requirement → Candidate → Assignment
Objects without outward responsibility do not expose unnecessary related lists.
Security Layer Recap
Skill Align security is layered deliberately:
- OWD → Record restriction
- Role Hierarchy → Organizational oversight
- Permission Sets → Persona capability control
- FLS → Field‑level lifecycle authority
- Page Layout → Structural consistency
- Lightning Record Page → Experience personalization
No single layer enforces governance—governance emerges from layered architectural design.