A recruiting to onboarding handoff fails in two directions. Too little context leaves the manager repeating interviews and discovering setup needs on day one. Too much context copies candidate notes, ratings, and sensitive details into an AI company brain that was built to answer employee questions. The fix is not a larger ATS export. It is a narrow, accepted handoff contract.
This guide shows how to define that contract, transfer only approved facts, assign every item to an owner, activate onboarding through the authoritative identity workflow, and prove that temporary handoff data was removed or restricted.
Why the hiring boundary needs its own design
Recruiting and onboarding use information for different jobs. A recruiting system helps a team evaluate candidates and administer a hiring process. An onboarding system coordinates work after a hiring decision. A company brain retrieves approved employee knowledge and explains what a new hire should do.
Those jobs overlap, but their records should not be merged. Interview feedback is not onboarding guidance. A recruiter's note about a requested schedule is not an approved employment arrangement. A start date in an offer workflow is not proof that an employee identity is active. When an integration treats every ATS field as reusable employee context, it strips away purpose, owner, and authority.
Use the NIST Privacy Framework as a practical reminder that privacy risk must be identified, governed, controlled, communicated, and protected. For this workflow, that means deciding why each field crosses the hiring boundary, who may use it, how long it remains, and what happens when it is wrong. The transfer should start from an allowlist, not from a full candidate object followed by attempted redaction.
No opened source covered the complete boundary contract. Individual tools can move attributes, create accounts, assign tasks, or search knowledge. The handoff must connect those actions without turning the candidate record into company-brain content.
Define the handoff outcome before mapping fields
The handoff is complete only when five conditions are true:
- The accepted hire is linked to one authoritative employee record.
- Approved onboarding facts have named destinations and owners.
- The hiring manager has accepted or corrected the operational context.
- The company brain can retrieve employee-approved onboarding material under the new identity's permissions.
- Temporary transfer data is deleted or restricted according to its recorded policy.
A webhook delivery does not satisfy those conditions. It proves only that one system sent a message. Model the handoff as a stateful business process with explicit outcomes such as prepared, awaiting_manager, accepted, activated, failed, and closed.
The identity lifecycle should remain authoritative. Microsoft Entra lifecycle workflows describes joiner, mover, and leaver automation driven by employee attributes and lifecycle events. Your stack may use another identity platform, but the design rule is the same: the company brain consumes verified identity and access state. It does not create trust from an ATS export on its own.
Build an allowlisted data contract
Start with the smallest set of facts needed to prepare the employee's first work. For each field, record its source, purpose, destination, owner, verification rule, and retention action.
| Source fact | Onboarding use | Destination | Acceptance owner | Rule |
|---|---|---|---|---|
| Legal name and employee identifier | Match the employee record | HR system | People Operations | Transfer through the approved HR integration |
| Confirmed start date | Schedule lifecycle tasks | HR and identity workflow | People Operations | Reject dates without an accepted employment state |
| Approved role, team, manager, and location | Select tasks and access requests | HR and onboarding workflow | Hiring manager | Manager must confirm before activation |
| Approved working arrangement | Prepare equipment and workplace tasks | Onboarding workflow | People Operations | Use the approved term, not a recruiter's free-text note |
| Named setup needs | Create owned follow-up tasks | Restricted case system | Assigned specialist | Pass a case reference, not sensitive details, to the company brain |
| Candidate interview notes and ratings | None | ATS only | Recruiting | Do not transfer |
This table is a design example, not a universal field list. Legal, privacy, HR, and security owners must approve the contract for the locations and systems involved.
Avoid using free text when a controlled value will work. A role identifier is safer to route than a paragraph describing the candidate. A case reference is safer than embedding accommodation, immigration, health, or compensation details in a general onboarding payload. If the company brain needs to tell a new hire whom to contact, it can retrieve the support route without retrieving the private case.
Represent the transfer as a versioned event rather than an unstructured prompt:
{
"event_type": "onboarding_handoff_prepared",
"contract_version": "1.0",
"employee_ref": "hr-record-reference",
"effective_start_date": "approved-date",
"role_ref": "approved-role-reference",
"manager_ref": "approved-manager-reference",
"location_ref": "approved-location-reference",
"task_refs": ["owned-task-reference"],
"source_system": "ats",
"acceptance_state": "awaiting_manager"
}The event contains references and approved routing values. It does not contain interview transcripts, model summaries of candidate performance, or private case details. Store the contract version so a later audit can explain which fields and rules applied.
Run the handoff as an acceptance workflow
Separate preparation from activation.
1. Trigger only from an accepted hiring state
Do not start from a stage label that recruiters can use informally. Require the state your organization treats as an approved hire, plus the identifiers needed to prevent duplicate employee records. If that state is reversed, stop downstream activation and open a controlled exception rather than silently deleting evidence.
2. Validate the payload against the allowlist
Reject unknown fields. Validate controlled values such as location, legal entity, role, manager, and start date against authoritative records. Quarantine a payload when its contract version is unsupported. This fail-closed behavior prevents a newly added ATS field from flowing into onboarding by default.
3. Create owned work, not a context dump
Convert approved facts into tasks with owners and due dates. The GitLab onboarding handbook provides a maintained practitioner example of pre-onboarding tasks, employee details, access requests, buddies, and named support responsibilities. The useful pattern is explicit ownership. A fact such as "manager not confirmed" should become a blocking task assigned to People Operations, not a sentence placed in the new hire's searchable profile.
4. Require manager acceptance
Show the hiring manager a concise handoff summary: role, team, location, start date, approved arrangement, first-week outcomes, and open tasks. Ask for accept or correct, not a passive acknowledgment. Record who accepted which contract version and when.
Manager acceptance does not authorize restricted access by itself. It verifies operational context before identity and onboarding assignments rely on it.
5. Activate from authoritative identity state
After acceptance, let the HR and identity lifecycle create or activate the employee identity. The company brain should apply that current identity and its permissions when serving knowledge. It should not expose onboarding pages merely because the ATS says the candidate was hired.
Kipwise's employee onboarding workflow illustrates the product-side destination: assigned reading, searchable company knowledge, and progress tracking. Feed that destination approved role and workflow references. Keep candidate evaluation records outside it.
6. Close and clean up the transfer
Confirm that the employee record exists, assigned tasks are owned, manager corrections were applied, and company-brain access resolves under the intended identity. Then remove temporary payload copies or restrict them under the approved retention rule. Closing the workflow should produce an outcome record, not preserve the entire transfer message forever.
Decide what the company brain may say
The assistant needs clear response boundaries during the transition.
It may explain approved onboarding tasks, identify the owner of an open request, link to current employee guidance, and report bounded states such as "waiting for manager confirmation." It should not summarize interview feedback, infer why a candidate received an offer, disclose private setup cases, or claim that access is ready before the authoritative system reports success.
When required context is missing, the answer should name the missing decision and owner. For example: "Your work location has not been confirmed in the employee record. People Operations owns that update, so location-specific onboarding tasks are paused." This is more useful than guessing from the candidate's address or a recruiter's note.
Handle failures without leaking more data
Plan recovery before enabling the integration.
When the start date changes
Recalculate due dates and identity activation from the authoritative employee record. Invalidate the old schedule instead of sending a second independent checklist.
When the manager rejects a field
Keep both the proposed and corrected controlled values in the handoff outcome record. Update downstream tasks from the accepted value. Do not edit the candidate record to make the discrepancy disappear.
When identity creation fails
Hold company-brain access and permission-dependent tasks. Route the failure to the identity owner with the employee reference and error category, not the full candidate payload.
When an unexpected field appears
Quarantine the event, record the contract mismatch, and notify the integration owner. Do not let the model decide whether the field looks sensitive.
When the same event arrives twice
Use an idempotency key based on the hire, contract version, and source event. Return the existing workflow state rather than creating duplicate accounts, tasks, or reading assignments.
When restricted data crosses the boundary
Stop further processing, restrict access to the payload, preserve only the evidence required for incident handling, and follow the organization's privacy and security process. Fix the allowlist or source mapping before replaying a clean event.
Test the complete boundary
A test should prove business outcomes and negative controls, not just API connectivity.
Use a synthetic hire and verify that approved fields create the expected employee reference, owner tasks, manager acceptance request, identity event, and onboarding assignments. Then test that interview notes, ratings, and private case details are rejected or absent. Change the start date and manager before activation. Deliver the same event twice. Send an unsupported contract version. Remove a required owner. Confirm that each case fails safely and leaves a clear recovery route.
Before launch, require evidence for these checks:
- The accepted report contains only allowlisted fields.
- Every transferred fact has a purpose, destination, and owner.
- Manager corrections reach downstream tasks before activation.
- Company-brain retrieval uses the activated employee identity.
- Restricted candidate fields never appear in search, prompts, logs, or onboarding exports.
- Duplicate and out-of-order events do not create duplicate work.
- Temporary transfer data follows the recorded cleanup action.
- A failed handoff can resume from the last accepted state without a full candidate export.
Add a negative search test. Put a distinctive phrase only in a synthetic interview note, then search the company brain for it. The result must be empty before and after onboarding activation.
Put one real handoff through the contract
Choose one role and map its current recruiting to onboarding handoff. List every fact people copy today, then classify each as transfer, task reference, manager confirmation, or ATS-only data. Assign an owner and cleanup rule to every transferred item.
Run a synthetic hire through the resulting contract before connecting live candidate records. Do not enable automated company-brain access until the manager acceptance, authoritative identity activation, negative search test, and cleanup check all pass.
References
- NIST Privacy Framework supports the privacy risk, governance, control, communication, and protection model used for the handoff contract.
- Microsoft Entra lifecycle workflows supports the authoritative joiner lifecycle and employee-attribute automation pattern.
- GitLab onboarding handbook supports explicit pre-onboarding tasks, access requests, owners, and support responsibilities.
- Kipwise employee onboarding supports the destination context for assigned reading, searchable employee knowledge, and onboarding progress.
