After establishing record-level governance in Skill Align, I focused on deeper system control.
Not just: Who can see records.
But:
Who can influence lifecycle.
Who can modify state.
Who can shape operational flow.
Today I focused on :
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:
- Skill
Purpose:
Define approved skills.
Support matching logic and reporting.
Remain stable over time.
OWD: Public Read Only
Editable only by Managers.
Catalog stability ensures reporting consistency and matching accuracy.
State Objects – Represent Business Definition State
State objects define structured requirements or capability conditions.
Objects:
Employee Skill
Project Skill Requirement
These objects represent defined capability conditions:
-
- Employee Skill → Recorded capability currently held.
- Project Skill Requirement → Capability required by a project.
Both represent structured state definitions rather than lifecycle movement.
OWD: Private
Ownership:
Employee Skill → Employee
Project Skill Requirement → Manager
State objects define what is required or what currently exists — not process transitions.
Transactional Objects – Represent Lifecycle Movement
These represent allocation and operational flow.
Objects:
Project
Project Candidate
Project Assignment
These objects move through lifecycle stages and require controlled transitions.
OWD: Private
Ownership:
Project → Manager
Project Candidate → Manager
Project Assignment → 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 assignment status but cannot modify it.
This centralizes allocation authority and prevents lifecycle bypass.
Catalog Stability Control
On the 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 Page Layout?
Page Layout defines:
Which fields appear in the Record Detail section
Which Related Lists are displayed
Which standard/custom buttons are available
Basic section grouping
It does NOT enforce security.
Security is enforced by:
OWD
Role Hierarchy
Permission Sets
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 using Lightning App Builder.
It 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.
Think of it this way:
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.
This is why Page Layout remains foundational.
Dynamic Forms: Presentation Shift, Not Governance Shift
Dynamic Forms allows fields to be placed directly onto the Lightning Record Page instead of using 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 structural fallback.
Dynamic Forms shifts 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.
In Skill Align, 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)
This is 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.
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.
Top comments (0)