Staffing & Recruiting
Hybrid staffing business models on Salesforce
Model contract staffing, permanent placement and project work without mixing their economics, delivery stages or access controls. Includes a worked example.
By Gosai Digital · 5 min read
Reviewed
A customer may buy temporary staff, a permanent hire and a scoped project from the same firm. The relationship is shared, but the work is measured differently. A single pipeline becomes misleading when “filled,” “delivered” and “invoiced” are treated as equivalent events.
The design goal is a consistent view of the customer with distinct, connected operational records where the lifecycles differ. This guide uses a fictional example. It does not prescribe a replacement for a managed ATS schema, and its financial examples are planning inputs rather than accounting conclusions.
Item 1: Shared customer context
Account access does not grant every child record
Item 2: Contract assignments and time
Hours × effective rates; finance reconciliation
Item 3: Permanent search and placement
Contractual fee and invoice trigger
Item 4: Project and milestones
Scope, acceptance and actual effort
Item 5: Finance-approved reporting
Consistent periods, units and access controls
Start with the unit of delivery
Write one sentence for each business line:
- Contract staffing: a worker serves an assignment, with billable and payable time governed by the agreed terms.
- Permanent recruitment: a search or job requirement progresses through candidate selection to a placement and an associated fee arrangement.
- Project services: a defined scope is delivered through milestones, time or another contractual billing basis.
- Referral business: the firm's entitlement depends on the specific introduction or referral agreement.
Then name the event that creates a forecast, the event that supports invoicing and the source that establishes recognized revenue. They may be different. Finance must determine the applicable accounting policy and period treatment; a Salesforce stage is not, by itself, evidence that revenue should be recognized.
Work through a mixed customer example
Illustrative customer: a manufacturer asks for two temporary production workers, a permanent maintenance manager and a six-week operational assessment.
Contract assignment A has a planned bill rate of $45 per hour, pay rate of $30 and 40 planned hours. Its unburdened planned bill-pay spread is $600 for that week: 40 × ($45 − $30). Assignment B must be calculated independently using its own hours and effective rates. Neither calculation includes employer burden, adjustments or verified actual time.
The permanent search has an illustrative agreed fee of $18,000. Track the contract's invoice trigger and any guarantee or replacement terms. Do not multiply that fee by assignment hours or treat a candidate interview as earned revenue.
The project has an illustrative $24,000 fixed fee, two agreed milestones and a separate effort budget. Track scope changes and milestone acceptance. A staffing pay-bill calculation cannot show whether the project is on budget, because unplanned delivery effort can consume the fee without changing its face value.
The Account brings these relationships together. Each delivery record retains its own terms, status, owner, identifiers and financial source references. The amounts demonstrate differences in units; they are not a combined revenue forecast or client outcome.
Use the model decision worksheet
For every proposed shared or separate object, record:
- Business event represented: sale, job requirement, candidate submission, assignment, project or invoice reference.
- Lifecycle: stages, repeat events and cancellation/correction paths.
- Cardinality: can one sale produce several assignments, or one worker serve multiple assignments?
- Required data: shared fields versus fields meaningful only to one service line.
- Access: who may see records and sensitive fields?
- History: what must remain stable when current terms change?
- System of record: ATS, Salesforce, project tool or finance system.
- Reporting: the level at which records may be compared without double counting.
Record types can be useful when the same underlying concept has modest process variations. Separate related objects are often clearer when lifecycles, repeated transactions or access requirements differ materially. Opportunity may represent the commercial sale; an existing package may use it differently. Assess package assumptions and downstream reporting before deciding to repurpose or replace it.
A shared “Business Line” field is helpful for grouping. It does not by itself model every relationship or establish who is allowed to see a record.
Design confidentiality independently of page design
Layouts and record types organize the experience. Field permissions, object permissions and record-access controls enforce distinct parts of the access policy. Hiding a rate on a recruiter layout is insufficient if the same user can expose it through another supported view. Salesforce field-level security
An illustrative access worksheet might say:
- Account manager: permitted customer relationship information and authorized commercial summaries.
- Contract delivery team: its assignments and the operational fields needed to service them.
- Project team: its scope, milestones and delivery records; no automatic access to unrelated candidate notes.
- Finance: the approved financial inputs required for reconciliation, with editing responsibilities defined separately.
Translate each row into actual object permissions, field permissions and record access. Review role hierarchy, sharing rules, broad administrative permissions and external access. Private organization-wide defaults are a starting point whose effect depends on other access grants. Salesforce record-access model
Also review custom components, integrations and automation execution contexts. A Flow running in system context with sharing respects record sharing but does not thereby enforce the running user's object and field permissions. Test the precise type, settings and API version in use. Salesforce Flow run context
Give leadership comparable dimensions and honest measures
Useful shared dimensions include customer, legal entity, branch, service line, period and responsible team. Useful measures remain specific:
- Contract staffing: actual billable hours, invoiced or recognized revenue as defined, direct labor cost and finance-approved margin.
- Permanent recruitment: searches, starts, fee status, replacement exposure and the agreed revenue measure.
- Projects: milestone progress, approved change orders, actual effort and budget variance.
A consolidated revenue view needs consistent periods, currency treatment and accounting definitions. A consolidated activity view needs explicit units. Two assignments, one placement and two milestones cannot meaningfully become “five placements.” Separate forecast from actual and label where finance reconciliation is pending.
Pilot the awkward combination
Use the mixed customer above as a sandbox test. Verify that a cancelled assignment does not cancel the permanent search; a project scope change does not alter unrelated rates; and a user permitted to see the Account cannot automatically see every confidential child record. Reconcile the reporting totals back to individual source records.
Record the design decision and its tradeoff. A single organization can make common customer context easier to use, but distinct legal, security, acquisition or operational needs can justify stronger separation. Choose from the actual constraints rather than a universal preference for one org or one object.
Discuss the model before adding fields
Talk to Gosai Digital about a hybrid staffing model. Bring one anonymized customer journey spanning two service lines, the existing system boundaries and the reports leadership needs. That reveals which information should be shared and which needs a separate lifecycle.