DEV Community: Rubasri Srikanthan

Building Skill Align - Part 7 - Project Staffing Assistant(Frontend)

Rubasri Srikanthan — Sat, 07 Mar 2026 09:46:25 +0000

In the previous part of this series, I built the backend logic that evaluates employees against project skill requirements and calculates a gap score.

With the backend logic in place, the next step was to design a frontend experience that helps managers interpret those results effectively.

Building the UI from an initial version to an improved dashboard

If you look at the first version of the Project Assistant UI, it displayed the data correctly, but the interface itself was quite plain and number-heavy.

Managers would have had to interpret a lot of raw information before making decisions.

That made me realize something important:

A decision-support system should not just display data — it should help users understand what the data means.

So I redesigned the interface to make the information more actionable and easier to interpret for project managers.

The Goal of the Frontend

The Project Staffing Assistant needed to answer three important questions for project managers:

Which employees are the best candidates for this project?
How risky is assigning this employee based on skill gaps?
Which specific skills contribute to that risk?

To support this workflow, I built a Project Staffing Overview dashboard.

Each employee is displayed as a candidate card containing key information. This layout allows managers to quickly evaluate candidates and assign them to the project.

Limiting Results with Top Candidate Selection

In my initial implementation, I hardcoded the system to return Top 5 candidates from the backend. At that stage, my focus was primarily on displaying the detailed skill breakdown.

My plan was to finish the core feature first and improve usability later.

However, while testing with a larger employee dataset, I realized that limiting results to a fixed number could restrict flexibility for project managers.

It required only:

a minor backend adjustment
a small UI enhancement

So I introduced a Top Candidate selector in UI.

Managers can now choose how many candidates they want to evaluate.

LWC Implementation

HTML

<lightning-combobox
    label="Top Candidates"
    value={topN}
    options={topOptions}
    onchange={handleTopChange}>
</lightning-combobox>

JS

topOptions = [
 { label: 'Top 5', value: '5' },
 { label: 'Top 10', value: '10' },
 { label: 'Top 20', value: '20' },
 { label: 'Top 30', value: '30' }
];

handleTopChange(event) {
    this.topN = event.detail.value;
    // call backend to fetch employees
}

Handling Assigned and Recommended Candidates

Initially, my approach was simple: return the Top N candidates for a project.

But after implementing the assignment functionality, I noticed an important usability issue.

If candidates from the Top N list get assigned, the system should ideally bring in the next eligible candidates so that managers still have enough options to choose from.

At the same time, managers should also have visibility into which candidates are already assigned.

Example:

Top 5 Candidates

A (Assigned)
B (Assigned)
C
D
E

In this scenario, managers effectively have only three new candidates to consider.

To solve this, I decided to return both:

Assigned candidates
Eligible new candidates

This ensures managers always see both current assignments and fresh recommendations, maintaining enough options when staffing the project.

Backend Support

To enable this behavior, I added a flag to the evaluation results.

@AuraEnabled public Boolean hasActiveAssignment;

During evaluation, Apex checks whether an employee is already assigned to the selected project.

candidate.hasActiveAssignment = activeAssignments.containsKey(
    buildProjectEmployeeKey(projectId, employeeId)
);

This flag allows the frontend to clearly distinguish between employees who are already assigned and new recommended candidates, giving managers better visibility while making staffing decisions.

Future Enhancement

As the dataset grows, I plan to introduce pagination, which will allow managers to navigate larger candidate lists more efficiently.

Risk-Based Evaluation

Initially, the backend returned a gap score, but raw numbers were not very intuitive for reviewing candidates.

So I introduced a new metric: Required Skills Risk

Example:

Required Skills Risk → 52% (Medium)

This metric focuses specifically on required project skills, giving managers a clearer picture of potential delivery risk when assigning an employee.

How Required Skills Risk is Calculated

The Required Skills Risk represents the delivery risk caused by gaps in required project skills.

Required Risk % = (Total Required Impact / 
                   Maximum Possible Required Impact) × 100

Total Required Impact → Sum of the impact values for all required skill gaps.
Maximum Possible Required Impact → The worst-case impact if an employee had no proficiency in any required skill.

To maintain transparency for managers, I also added a tooltip explaining the calculation.

HTML

<lightning-helptext
 content={riskHelpText}>
</lightning-helptext>

Expandable Skill Breakdown

High-level metrics are useful, but sometimes managers need deeper insight before making an assignment decision.

To support this, I added an expandable skill breakdown.

When expanded, the dashboard displays detailed skill gap information. This allows managers to quickly understand why a candidate has a certain risk score.

Toggle Implementation LWC

HTML

<lightning-button
 label={toggleLabel}
 onclick={toggleSkills}>
</lightning-button>

<template if:true={showSkills}>
   <!-- Skill breakdown table -->
</template>

JS

showSkills = false;

get toggleLabel() {
 return this.showSkills ? 'Hide Risk Breakdown' : 'View Risk Breakdown';
}

toggleSkills() {
 this.showSkills = !this.showSkills;
}

This keeps the primary view simple, while still allowing detailed inspection on demand.

Skill Metadata with Informational Pills

Each skill row also displays contextual indicators that help managers interpret the data quickly.

HTML

<lightning-pill label={skill.importance}></lightning-pill>
<lightning-pill label={'Weight ' + skill.weight}></lightning-pill>
<lightning-pill label={skill.source}></lightning-pill>

Skill-Level Risk Visualization

Instead of simply listing missing skills, the UI highlights risk contribution for each skill.

This logic is calculated in Apex using the impact value, which combines:

skill deficit
skill importance
skill weight

Example:

SOQL → 80% (High Risk)
LWC → 40% (Medium Risk)
OmniStudio → 10% (Low Risk)

Risk Bucket UI

HTML

<lightning-badge label={skill.riskBand}></lightning-badge>

Each skill is categorized into a risk band:

High
Medium
Low
None

This makes it easy for managers to quickly identify which skills contribute most to delivery risk.

Readiness Indicator LWC

Each candidate card also includes a Project Readiness badge.

Employees are classified as:

Ready – Required skills sufficiently met

Not Ready – Significant skill gaps remain

HTML

<lightning-badge label={employee.readiness}></lightning-badge>

Assignment Action

Managers can assign employees directly from the dashboard.

HTML

<lightning-button
 label={employee.assigned ? 'Assigned' : 'Assign'}
 variant="brand"
 disabled={employee.assigned}
 onclick={assignEmployee}>
</lightning-button>

If an employee is already assigned, the button is automatically disabled. This prevents duplicate assignments and keeps the workflow simple.

Styling

For styling, I used SLDS (Salesforce Lightning Design System) along with custom CSS where necessary.

Final Thoughts

Building the Project Staffing Assistant taught me an important lesson:

A system is not only about correct logic.

It is also about presenting information in a way that helps people understand, trust, and act on it effectively.

Glossary

LWC (Lightning Web Components)

A modern JavaScript framework used in Salesforce to build fast and reusable UI components.

SLDS (Salesforce Lightning Design System)

A design framework that provides prebuilt styles and components for building consistent Salesforce user interfaces.

Building Skill Align - Part 6 - Project Staffing Assistant(Backend)

Rubasri Srikanthan — Thu, 26 Feb 2026 10:20:07 +0000

I started with the first feature in this project: Project Staffing Assistant.

Project Staffing Assistant helps managers decide which candidates are suitable for a project based on actual project requirements.

I began with the backend, building the intelligence layer in Apex.

The Core Service – SkillEvaluatorService

public with sharing class SkillEvaluatorService

Two important design decisions:

public → Required because LWC will call this Apex class
with sharing → Ensures record-level security is respected

I had previously configured roles, OWD, and sharing rules (Refer here).
Using with sharing ensures this evaluation logic follows those configurations.

Apex Sharing Behavior:

Apex runs in system context by default. Object-level and field-level permissions are not automatically enforced.
with sharing enforces record-level sharing rules only, ensuring queries and DML respect the current user’s access.
with sharing does not enforce object or field permissions. You must explicitly handle CRUD/FLS (e.g., WITH SECURITY_ENFORCED or Security.stripInaccessible()).
If no sharing keyword is defined, the class inherits sharing from its caller, so behavior may vary depending on depending on how it is invoked.
Triggers run in system context. Even if a helper class is marked with sharing, the trigger executes in system mode.

Designing Data Transfer Objects

Instead of returning raw Employee__c or Employee_Skill__c records, I created Data Transfer Objects or DTOs.

DTOs define the structured connection between backend and UI. They wrap only the fields required by the frontend, preventing unnecessary exposure of internal data.

For this feature, the UI needed:

Detailed skill gap information (for manager-level decision making)
Candidate-level summary information

Note: @AuraEnabled is required for LWC(UI) to access Apex properties and methods.

Skill-Level DTO

public class SkillGapDetail {
    @AuraEnabled public String skillName;
    @AuraEnabled public Integer requiredLevel;
    @AuraEnabled public Integer impact;
}

Represents a single skill gap for a candidate.

Advantages:

All evaluation logic runs in Apex, so UI performs no calculations
Business logic stays in the backend
UI remains lightweight
Future logic changes don’t affect frontend code

Candidate-Level DTO

public class CandidateResult {
    @AuraEnabled public String employeeName;
    @AuraEnabled public Decimal gapScore;
    @AuraEnabled public Boolean isProjectReady;
    @AuraEnabled public SkillGapDetail detail;
}

For each evaluated employee, the UI receives:

Employee name
Final gap score
Ready / Not Ready flag
Skill Gap Detail

This keeps the response clean and structured.

Entry Point – evaluateProject()

@AuraEnabled
public static List<CandidateResult> evaluateProject(Id projectId, Integer topN)

Responsibilities:

Accept a Project Id
Evaluate unallocated employees
Rank them
Return top N candidates
Persist evaluation results

Guard Clause

Guard clauses help prevent unnecessary processing and avoid unexpected or confusing UI behavior.

if (projectId == null) return new List<CandidateResult>();

If no project is provided, evaluation stops.

Prevents:

Null pointer exceptions
Unexpected UI errors
Wasted governor limits

Load Project Requirements

List<Project_Skill_Requirement__c> reqs = [
    SELECT Skill__c, Required_Level__c,
           Importance__c, Weight__c
    FROM Project_Skill_Requirement__c
    WHERE Project__c = :projectId
];

Each requirement contains:

Skill
Required Level
Importance (Required / Nice-to-have)
Weight

After fetching, I converted them into Maps for fast access.

Why Maps?

Governor limits restrict queries per transaction. Querying inside loops risks hitting limits. By storing data in Maps:

Avoid repeated SOQL calls
Ensure constant-time lookups (O(1))
Keep code bulk-safe

Maps are essential in Apex for this reason.

Weighted Impact Formula

This is the heart of the evaluation engine.

I first compute the deficit to rank candidates:
deficit = requiredLevel - employeeLevel;

By itself, this treats all skills equally. To make evaluations more realistic, I introduced weighted scoring:

Integer impact = deficit * importanceMultiplier * weight;

Where:

Required skill → multiplier = 2
Nice-to-have → multiplier = 1
Weight → configurable per skill

From this I ensured,

Missing a critical skill has higher impact
Minor skills don’t disproportionately penalize a candidate

The result is a system that is realistic and flexible rather than rigid.

Effective Level – Making It Smarter

Raw skill levels aren’t always reliable. To improve accuracy, I introduced two adjustments:

Confidence adjustment
Staleness adjustment

1. Confidence Adjustment

Boolean isTrusted = (src == 'Manager-assessed');
Integer confidenceAdjust = isTrusted ? 0 : 1;
Integer afterConfidence = rawLevel - confidenceAdjust;

Self-assessed → reduce slightly
Manager-assessed → keep unchanged

2. Staleness Adjustment

Date staleCutoff = Date.today().addMonths(-12);

if (lastVerified == null) {
    stalenessAdjust = 2;
} else if (lastVerified <= staleCutoff) {
    stalenessAdjust = 1;
}

Never verified → larger reduction

Verified >12 months ago → slight reduction
Finally, the effective level is computed as:

Integer effectiveLevel = afterConfidence - stalenessAdjust;
if (effectiveLevel < 0) effectiveLevel = 0;

This makes the evaluation time and credibility aware, preventing outdated or inflated skill ratings from misleading staffing decisions.

Ranking Candidates

results.sort(new CandidateComparator());

Custom comparator:

private class CandidateComparator implements System.Comparator<CandidateResult> {
    public Integer compare(CandidateResult x, CandidateResult y) {
        if (x.gapScore != y.gapScore) {
            return (x.gapScore < y.gapScore) ? -1 : 1;
        }
        return x.employeeName.toLowerCase()
               .compareTo(y.employeeName.toLowerCase());
    }
}

Sorting priority :

Lowest gap score
Alphabetical order as tie-breaker

Using this comparator ensures deterministic sorting, providing consistent results across repeated evaluations.

Project Ready Logic

cr.isProjectReady = (requiredImpact == 0);

If all required skills have zero impact, the candidate is ready.

Nice-to-have gaps don’t block readiness, preventing unnecessary hiring when existing employees are suitable.

Persisting Recommendations

The evaluation results are stored in the Project_Candidate__c object.

A composite key is used to uniquely identify each candidate for a project:

pc.Project_Employee_Key__c =
    String.valueOf(projectId) + '|' + String.valueOf(employeeId);

Note: - The Project_Employee_Key__c is a Text field marked Unique and Required.

The records are then saved using:

upsert candidates Project_Employee_Key__c;

upsert ensures:

Insert if record doesn’t exist
Updates the record if it already exists
Prevents duplicate records
Allows re-evaluation to update previous scores

Building Skill Align - Part 5 - Field-Level Security, Page Layout Strategy & Lightning Pages

Rubasri Srikanthan — Mon, 23 Feb 2026 14:16:02 +0000

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.

Building Skill Align - Part 4 - Roles, OWD, Sharing & Record-Level Governance

Rubasri Srikanthan — Sun, 22 Feb 2026 12:54:03 +0000

After defining objects, users, profiles, and permission sets in Skill Align, the next critical layer was not functionality — but visibility.

Because defining what users can do without defining what they can see leads to overexposure.

In Salesforce, record-level security operates in layered form:

Organization-Wide Defaults (OWD) → Baseline visibility
Role Hierarchy → Vertical access expansion
Sharing Rules → Controlled horizontal exceptions

Profiles and Permission Sets define object-level permissions.

This phase I focused purely on record-level governance.

Important: Role Hierarchy and Sharing Rules can only expand access. They can never be more restrictive than OWD. OWD is always the foundation.

Organization-Wide Defaults (OWD)

What is OWD?

OWD defines the most restrictive level of access to records.

Common values:

Private → Only the record owner can access
Public Read Only → Everyone can view, only owner can edit
Public Read/Write → Everyone can view and edit

Security begins here.

OWD Configuration in Skill Align

I intentionally started restrictive and expanded access only where required.

Object	OWD	Reason
Employee	Private	Sensitive employee data
Project	Private	Allocation decisions must remain controlled
Skill	Public Read Only	Shared reference data
Employee Skill	Private	Skill ownership tied to employee
Project Skill Requirement	Private	Controlled requirement metadata
Project Candidate	Private	Shortlisting is sensitive
Project Assignment	Private	Final allocation must be governed

What This Means Practically

Because most objects are Private:

Users can only see records they own.
Access expands only through hierarchy or administrative override.
Exposure is controlled by design — not by accident.

Role Hierarchy

What is Role Hierarchy?

Role Hierarchy provides vertical record visibility.

When:

OWD = Private
“Grant Access Using Hierarchies” is enabled

Users higher in the hierarchy automatically gain access to records owned by users below them.

Important distinction:

Profiles → Control object permissions
Roles → Control record visibility

In Skill Align:

Managers and Employees share the same profile.

They differ only by role — and that drives visibility.

Role Structure

   HR
    ↑
Project Manager
    ↑
Employee

Visibility follows structure.

How Visibility Works in Skill Align

Scenario 1: Employee Skill Record

An Employee updates their Skill record.

The Employee can see and edit their record (owner).
The Project Manager can see it because they sit above the Employee in the hierarchy.
HR can see it due to administrative permissions.

This enables skill verification without exposing peer data.

Scenario 2: Project Assignment

Project Assignment records are owned by the Project Manager to reflect accountability.

The Project Manager can view and manage the record (record owner).
HR can see and modify it due to administrative permissions.
Employees cannot automatically see it because:
- OWD is Private.
- Their role sits below the Manager role.
- Ownership represents responsibility.

Governance is embedded into ownership.

HR and Administrative Override

HR uses the System Administrator profile, which includes:

View All Data
Modify All Data

These permissions override OWD and hierarchy.

HR visibility is administrative — not inherited.

This separation ensures:

Structural governance through roles
Oversight through administrative control

Sharing Rules

What Are Sharing Rules?

Sharing Rules allow access to be extended horizontally — outside reporting lines.

Used for:

Cross-team allocation reviews
Governance committees
Audit visibility

They expand access but never restrict it.

Did Skill Align Use Sharing Rules?

Not in this phase.

Because:

Upward visibility is already handled via Role Hierarchy.
Manager-owned records are intentionally restricted.
Governance is preserved through restrictive OWD.

If employee visibility into Project Assignments becomes necessary, a controlled sharing rule can be introduced — without redesigning the architecture.

The foundation is scalable.

Final Visibility Flow

Employee

Can see only records they own.
Cannot see peer records.
Cannot see Manager-owned Project Assignments.

Project Manager

Can see Employee-owned records below them.
Owns and governs Project Assignment records.
Controls allocation lifecycle.

HR

Full record visibility.
Administrative oversight.
Can verify skills and confirm allocations.

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

Rubasri Srikanthan — Sat, 21 Feb 2026 12:10:08 +0000

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

Building Skill Align - Part 2 - Objects, Relationships & Fields in Salesforce

Rubasri Srikanthan — Fri, 20 Feb 2026 14:56:11 +0000

When I started building Skill Align, the first step was to lay down the foundation: defining its core objects, relationships, and key fields. Think of this as creating the blueprint that makes the system actually work.

Quick Salesforce Terms for RDBMS Fans

If you’re coming from a relational database background, here’s a simple mapping:

Objects → store data, like tables
- Standard Objects – provided by Salesforce
- Custom Objects – created by you
Fields → define what each record contains, like columns
- Supports data types like Text, Picklist (select a single predefined value from multiple options), Number, Date/Time, and more
Records → the actual data, like rows

Relationships Connect the Dots

Lookup → flexible reference; parent has limited control over child
Master-Detail → tightly linked; parent controls ownership of child

Both are ideal for one-to-many relationships, but what about many-to-many?

Junction objects → solve M:N relationships by connecting two objects, usually via master-detail links to both objects.

💡 Best practice: Use standard objects whenever possible. Create custom objects only when necessary.

From Idea to Implementation

For Skill Align, the goal was clear: assign Employees with certain skills to Projects requiring those skills. That led to defining the core objects:

Employee

Represents people in the company.

Note: Normally, Employee would just be the User standard object. But in a Dev org, creating users requires licenses, so I created a separate Employee object.
Key fields:
- Is Allocated (Checkbox) → tracks whether the employee is assigned to a project
- Primary Manager (Lookup to Employee) → tracks reporting lines and helps with allocation

Skill

Stores all organizational skills and categorizes them for reporting and clarity.

Project

Stores project information. Linked to a manager via a lookup to Employee.

Project Candidate

Tracks potential employees for a project.

Key fields:
- Gap Score → difference between required skill level and employee’s actual level
- Is Project Ready (Checkbox) → tracks readiness

Project Assignment

Records final allocation of an employee to a project.

Key field:
- Status (Picklist: Proposed, Confirmed, Released) → tracks employee stage in the project

Why Many-to-Many Relationships Matter

Employees ↔ Skills

An employee can have many skills, and a skill can belong to many employees. This is solved using the Employee Skill junction object, with key fields:

Level → employee’s proficiency in the skill
Confidence → how confident the employee feels using this skill
Verification → whether the skill has been formally verified

Projects ↔ Skills

A project may require multiple skills, and a skill can belong to multiple projects. This is solved using the Project Skill Requirement junction object, with key fields:

Required Level → the proficiency level needed for the project
Weight → the relative importance of this skill for the project
Importance → the priority of this skill in decision-making

Fun Fact: Even using lookup relationships, Salesforce can treat the object like a junction:

Each requirement has independent ownership
Records can exist even if the Project or Skill is deleted
Metadata like Required Level or Weight is managed flexibly

This approach gives you junction-like behavior without strict master-detail constraints, perfect when you want flexibility.

Next Steps

After planning, I created these objects and connected the relationships in Salesforce. This structure now allows Skill Align to match employees to projects based on skills and readiness, while remaining flexible for future growth.

Of course, as new features come in, more objects and fields may be required—but Salesforce makes it easy to extend the data model whenever needed.

💬 Question for you: How do you manage data architecture in your projects?

Starting My First Salesforce Project - What Is Salesforce?

Rubasri Srikanthan — Thu, 19 Feb 2026 13:30:05 +0000

When I started my job as a Salesforce Developer, my Amma asked:

“So Salesforce is the technology you're working on… is it a sales job? Do you need to sell?😅”

I paused. Then I laughed.

I told her:

“No Amma 😭 It’s not about selling products. It’s about building systems.”

Let me explain the same in a simple way.

Imagine a big theatre with multiple customers, employees, movies, and tickets — all managed using Excel sheets and emails.

In today’s fast-paced world?

Chaos. Absolute chaos.

That’s where 👉 Salesforce comes in.

Salesforce is a cloud-based CRM (Customer Relationship Management) platform that helps companies:

📦 Store and manage data - Customers, Movies, Bookings, Payments — everything in one structured system.
⚙️ Automate business processes - Automatically allocate movies to Mini or Maxi theatre.
🔐 Control user access - Theatre Manager and Employee should not see the same data.
🏗️ Build custom applications - Entire Movie Ticket Management App — from booking to feedback.

So no… it’s not a sales job.

It’s about designing and developing structured, scalable business systems, automating business logic and solving real-world operational problems.

It’s system architecture + development + business understanding combined.

But my Amma's reaction - Oh, then you help them to increase their sales... Fine.

Even though I was unable to explain her fully, she got the basics right 😊

Because at the end of the day, well-built systems do help businesses grow.

Why I Decided to Build Something Real

Once I truly understood what Salesforce enables, I didn’t want to just learn it from documentation or Trailhead (Official learning documentation of Salesforce).

I wanted to build a real system from scratch.

That’s how Skill Align was born.

What Is Skill Align? 💡

In many organizations, employee allocation to projects often depends on:

Availability
Manager assumptions
Informal discussions
Quick decisions

But not always on structured skill evaluation.

This affects almost every employee - without structured skill tracking, talent is often underutilized or misaligned.

Skill Align is my attempt to design a system where:

Employees have clearly defined skill records
Projects specify required skills and expected proficiency levels
Allocation decisions are based on data, not perception
Skill gaps can be identified before assigning someone

Instead of asking,

“Who seems suitable?”

The system should answer,

“Who is the best match based on skills and requirements?”

That’s the vision.

What this Series Is About 🚀

Instead of building this silently, I’ve decided to document the journey.

Starting now, I will be sharing:

What I build each day
Why I design it that way
Architecture decisions
Data modeling logic
Challenges and learnings
Improvements and redesigns

This is not a step-by-step tutorial.

This is my real-time journey of building a Salesforce application from scratch.

If you’re learning Salesforce, transitioning into development, or curious about how real systems are structured — this series might give you practical insight beyond theory.

Would love to hear your parents’ views about your job too 😄

About Me

I’m a curious Salesforce Developer who loves turning complex ideas into simple, practical solutions.

Using Apex to Parse AI Outputs safely in Salesforce

Rubasri Srikanthan — Fri, 13 Feb 2026 17:10:07 +0000

While building my project, I came across a use case where I needed to capture AI-generated data using Flow and store it directly in Salesforce object fields. The goal was to store this data for later use.

Although Flow is powerful for automations, AI outputs are not formatted in a way that Flow can reliably use. This challenge led me to explore how Apex and Flow could work together to safely process AI outputs before storing them in Salesforce records.

Why a Parser is Needed

Even when AI can be instructed to return structured JSON, Flow can struggle with:

Nested or inconsistent data
Extracting specific values reliably

Without a parser, automation can fail or store incomplete data. An Apex parser safely extracts the required fields and makes them available to Flow without modifying the AI-generated values.

Workflow: Step by Step

Here’s how I handled the use case in my project:

1. Generate AI Output Using Prompt Template

To make parsing simple, it’s important to instruct the AI to return structured JSON, for example:

{  
   "score": 85, 
   "confidenceLevel": "high" 
}

Clearly specify the fields you need and which values are optional.
In Flow, I used the Prompt Template action to get the generated AI output.

💡 Tip: Effective prompts generate predictable JSON, making it much easier for the parser to extract the values accurately.

2. Capture AI Output in Flow

Flow stores the AI response in a variable, ready to be passed to Apex for parsing.

3. Call Apex Parser from Flow

Flow sends the AI output variable to an Apex action.
The parser safely extracts the required fields and handles any missing or optional data.

Understanding the Apex Parser

Here’s the core of the parser:

Map<String, Object> data = (Map<String, Object>) JSON.deserializeUntyped(aiJson);

Decimal score = data.containsKey('score') 
    ? Decimal.valueOf(String.valueOf(data.get('score'))) 
    : null;

String confidence = data.containsKey('confidenceLevel') 
    ? String.valueOf(data.get('confidenceLevel')) 
    : null;

JSON.deserializeUntyped converts the JSON string into a map.
The map lets us safely check for missing fields.
Values are converted to the correct type, or set to null if missing.
The parser does not modify the AI-generated values; it only extracts them safely for Flow.

Key points for calling Apex from Flow

* @InvocableMethod lets Flow call the Apex parser
* @InvocableVariable allows data to pass in and out.

4. Flow Receives Parsed Data and Updates Records

Flow receives the extracted fields as variables.
These variables are mapped directly to Salesforce object fields.
Flow can now create or update records safely, without worrying about missing or malformed AI output.

Best Practices

Start by parsing a few key fields before handling everything.
Keep a log of raw AI outputs for debugging purposes.
Test the AI prompts and parser together to ensure consistent and predictable results.

About Me

I’m a curious Salesforce Developer who loves turning complex ideas into simple, practical solutions — and sharing what I learn while building projects.

Trigger.new vs Trigger.old — Understanding Apex Triggers the Right Way

Rubasri Srikanthan — Fri, 06 Feb 2026 15:06:00 +0000

When I first started learning Apex triggers, I wasn’t always sure when to use Trigger.new versus Trigger.old.

By focusing on how they actually work, I was able to grasp it clearly and apply it effectively.

Core Idea

Trigger.new → the data Salesforce is trying to save right now.

Trigger.old → the data that existed before the change.

Keeping this in mind, most usage scenarios become logical.

1. When to Use Trigger.new

What it represents:

Trigger.new contains the current or incoming values that Salesforce is attempting to insert or update.

Common use cases:

Validations
Setting or modifying field values
Reading updated values
Creating related records based on new data

Available in these contexts:

Scenario	Available?
Insert	Yes
Update	Yes
Undelete	Yes

Undelete: This trigger context runs when a record is restored from the Recycle Bin, and Trigger.new contains the record values being recovered.

Example: Validation

for (Contact con : Trigger.new) {
    if (con.Email == null) {
        con.Email.addError('Email is required');
    }
}

This works because Trigger.new represents the data being saved right now.

2. When to Use Trigger.old

What it represents:

Trigger.old is a snapshot of the record before the change.

Common use cases:

Detecting field changes
Conditional logic based on previous values
Preventing duplicate actions

Available in these contexts:

Scenario	Available?
Update	Yes
Delete	Yes

Example: Detecting a change

for (Opportunity newOpp : Trigger.new) {
    Opportunity oldOpp = Trigger.oldMap.get(newOpp.Id);
    if (newOpp.StageName != oldOpp.StageName) {
        // Stage has changed
    }
}

Trigger.old is useful because it gives you the previous state of the record for comparison.

Tip: Trigger.oldMap and Trigger.newMap provide fast access to records by Id (Id → Record). Using maps is preferred over looping when comparing old and new values in bulk operations.

3. Using Trigger.new and Trigger.old Together

Whenever your logic depends on detecting a change, not just the current value, you need both.

Example: Detecting a meaningful update

for (Opportunity newOpp : Trigger.new) {
    Opportunity oldOpp = Trigger.oldMap.get(newOpp.Id);
    if (newOpp.StageName == 'Closed Won' &&
        oldOpp.StageName != 'Closed Won') {
        // Stage just changed to Closed Won
    }
}

Using both helps prevent:

Duplicate execution
Logic running on unrelated updates
Incorrect automation

4. Context-Based Decision Table

Requirement	Use
Validate input	Trigger.new
Modify fields	Trigger.new
Compare old vs new	Trigger.new + Trigger.old
Cleanup before delete	Trigger.old
Block record save	Trigger.new.addError()

5. Before vs After Triggers

Trigger Type	What to Do
Before	Modify Trigger.new
After	Read Trigger.new, compare with Trigger.old

Important: You cannot modify records using Trigger.new in after triggers because the record has already been committed to the database. At this stage, Salesforce marks Trigger.new as read-only to preserve data integrity. Any further changes require a separate DML operation.

Example : Updating in after trigger using DML

List<Account> accsToUpdate = new List<Account>();
for (Account acc : Trigger.new) {
    accsToUpdate.add(new Account(
        Id = acc.Id,
        Name = 'Updated Name'
    ));
}
update accsToUpdate;

6. Trigger Timeline

Think about triggers in terms of whether a record already exists and what Salesforce is doing with it.

Trigger Context	Available Data	Purpose
Before Insert	Trigger.new	Record does not exist yet, modify fields before save
Before Update	Trigger.new + Trigger.old	Compare old vs new, modify fields before save
After Update	Trigger.new + Trigger.old	Record saved, read-only, detect changes
Before Delete	Trigger.old	Record about to be deleted, cleanup logic
After Delete	Trigger.old	Record deleted, read-only, audit or related logic

Visualizing the timeline of data makes using the correct context natural.

Final Thought

Instead of memorizing rules, I always ask:

“Am I working with new data, old data, or a change between them?”

Once you answer that, the correct context (Trigger.new, Trigger.old, or both) becomes obvious.

Pro Tips

Always bulkify your triggers — loop over collections like Trigger.new instead of single records to avoid governor limits.
Use Trigger.newMap and Trigger.oldMap for efficient lookups by Id instead of nested loops.

About Me

I’m a curious Salesforce Developer who enjoys breaking down complex concepts into simple, practical explanations.