A Practical Salesforce Data Model for Staffing

A staffing data model should answer a simple question: what happened between this candidate, this job and this client? It also needs to preserve the answer when a recruiter moves teams, an assignment is extended or a client's details change.

The model below is a reference for those decisions. It is not a prescription to create three new custom objects. A managed Salesforce ATS may already provide these concepts, and a smaller operation may combine some lifecycles successfully. Start with business meanings and the existing system before changing the schema.

Separate the business concepts first

These concepts deserve explicit definitions, even when your ATS uses different names:

• Client: the organization buying staffing services. Distinguish contracting entity, billing entity and worksite; an Account hierarchy can describe organizational relationships, but it does not establish your billing rules.
• Candidate: a person whose identity persists across applications and assignments. Decide how client-contact and candidate roles coexist when one person is both.
• Job: a requisition or staffing request, including its client, location, requirements and openings. Decide whether recurring shifts require separate records beneath it.
• Submission: one candidate's consideration for one job, with selection stages, dates and outcome. Repeat applications may need separate attempts rather than overwriting a previous decision.
• Placement or assignment: an agreed engagement, including start, end, cancellation and extension behavior.
• Commercial opportunity: a potential sale, such as a new account agreement, retained search or contract renewal.

Salesforce's standard Opportunity model describes potential sales. Opportunity can also deliberately represent a placement pipeline where its stages, amount, close date and forecasting behavior fit that lifecycle. Document that choice. If commercial pursuits and fulfillment proceed independently, separate records usually make the distinction easier to maintain. Neither approach removes the need to represent multiple candidates against a job.

Before extending a managed ATS, inspect its supported objects, identifiers, APIs and extension points with the vendor. Salesforce's managed-package rules vary by component and property. A second custom Placement object can create a competing source of truth rather than solve a reporting problem.

Work through an illustrative staffing example

Consider a fictional agency filling two laboratory-technician jobs for different facilities of the same client. Alex is considered for both, interviews for one and accepts an assignment there.

The conceptual model reads as follows:

• The client relates to two jobs, each associated with its worksite.
• Alex's candidate record relates to two submissions, one per job.
• Each submission retains its own selection outcome.
• The accepted submission links to an assignment; the declined submission remains available for authorized reporting.
• The assignment links to effective-dated terms and the relevant external payroll or invoicing identifiers.

An extension changes the assignment's agreed terms according to a defined amendment policy. It does not overwrite the earlier submission outcome. A future application creates another submission, so Alex's Contact does not need a single status that somehow means both “currently working” and “interviewing elsewhere.”

These are logical relationships. The diagram does not imply that every link should be a Salesforce master-detail field.

Choose relationships by ownership and retention

Use this decision matrix before implementing the links:

For master-detail records, sharing depends on the master. A two-master junction requires appropriate access to both masters, alongside object permissions. See Salesforce's custom-object security rules.

Deleting a master can delete its detail records; a two-master junction can be deleted when either parent is deleted. That is a consequential choice for assignment history. Lookup relationships offer different deletion behaviors depending on configuration and eligibility, so do not assume that every lookup preserves its child. Verify the actual fields against Salesforce's relationship considerations, then test deletion and recovery in a sandbox.

Keep attribution and access distinct

Record ownership is useful for operational responsibility. It is an unreliable historical commission record if ownership changes later. Where required, record recruiter participation, role, effective dates and approved credit on the relevant job or assignment. Agree whether credit totals must equal a defined allocation, and preserve the approved version.

A Business Unit field can classify transactions. It does not grant or deny access. Likewise, record-type assignments do not determine record visibility. Use object permissions, field-level security and record sharing for their respective access requirements.

If a client or candidate participates in several brands, one picklist may misrepresent the relationship. Consider brand-affiliation records while recording the accountable brand and legal entity on each transaction. Cross-brand candidate access needs an agreed privacy and operating policy. Also check Salesforce's private-contact behavior before treating Contacts without Accounts as a shared candidate pool.

Preserve history and system boundaries

Store agreed rate changes with effective dates when historical calculations depend on them. A report that multiplies past hours by today's rate can rewrite yesterday's apparent performance.

Keep expected assignment value, approved worked time, invoiced revenue and payroll cost distinguishable. Placement data can inform financial reporting; it is not automatically the accounting source of truth. Identify the authoritative system for each fact and how corrections, credits and cancellations return to Salesforce.

Select important fields for history tracking before launch. Salesforce begins tracking when the feature is enabled; it does not reconstruct earlier changes. Check retention and coverage against your requirements, and separately design preservation of contractual evidence and transactional history.

Prove the model before migrating

Test a candidate with concurrent submissions, a multi-opening job, a canceled start, an extension, a recruiter transfer and a client served by two brands. Check each scenario as a recruiter, finance user and integration identity. Confirm what each can read, change and delete, then reconcile reports to the authoritative systems.

For the wider governance decision, see multi-brand Salesforce architecture. One org and multiple orgs both involve tradeoffs; neither follows automatically from this reference model.

Bring a workflow, an existing object map and the reports you cannot reconcile. Talk through your staffing data model with Gosai.