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 skillConfidence→ how confident the employee feels using this skillVerification→ 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 projectWeight→ the relative importance of this skill for the projectImportance→ 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?
Top comments (0)