On this page0
Unfamiliar word? See Glossary: words used in these docs. Looking for the tasks in order? Begin at Start Here.
Reference
Included in: Team and Advanced. Which Plan Includes What
Signed Offer To Onboarding (Zero-Touch)
What happens between a candidate signing their offer and their accounts and equipment being ready: the signature starts an onboarding run, and once the approvals on it are given, Zonitix creates the accounts in the systems you have connected.
AI Screening With Identity-Anonymized Review
Screening scores each candidate against the job’s requirements by matching the résumé’s text to the job’s requirement terms; a small model that runs on your instance (Qwen 3 0.6B by default, with Qwen 2.5 0.5B as the lighter option) builds that list of terms. Before a résumé is scored, these are replaced with placeholders in its text: the candidate’s own name and any labelled name; email addresses, phone numbers and web addresses; age, date of birth and birth year; graduation years and ranges of years; labelled gender, marital status, nationality, citizenship, religion and ethnicity; mentions of citizenship, residency or work-visa status; and labelled addresses or locations. The keyword fallback scores the same cleaned text.
Heuristic Fallback Engine
To keep screening available even if the local LLM microservice is under heavy load, a local keyword-intersection heuristic acts as an instant fallback.
Contract Signed
Candidate signs the offer with the built-in Zonitix Sign engine.
Hardware Selected
Candidate chooses their OS and equipment in the portal.
Trigger Event
Zonitix Sign fires its completion callback, marking the candidate "Ready".
Provisioning Run
A run is generated with the persona's steps; accounts are created in the providers you have connected.
Hardware Assignment
A place is reserved in the device inventory for the new hire’s computer, and IT records its serial number.
The candidate’s portal does not stay open for ever. It closes at once if the candidate is rejected or the offer is withdrawn, declined or rescinded; otherwise it stays open until the end of the start day, and the link’s own expiry decides only when the offer has no start date. The full rules are under “The Candidate’s Offer Portal” in Recruitment & Hiring.
Zero-Touch IT Handoff
Once the candidate signs their agreement and chooses their laptop, Zonitix creates an onboarding run. When the approvals on that run have been given, it creates their company accounts in the systems you have connected and records their computer in the device inventory.
One Queue, Not Five
A Place In The Inventory
Priced Out Before It Runs
Which Providers Really Fire
Every provider below performs real API calls — Microsoft Entra ID, Okta, Google Workspace, Active Directory / OpenLDAP, AWS IAM, Slack, GitHub, Zoom, Jira, Salesforce, BambooHR, 1Password, Zendesk, ServiceNow, Dropbox and any app connected through Generic SCIM 2.0. Each needs a configured, active, verified provider hook. What offboarding does depends on the provider: Microsoft Entra ID and Slack accounts are disabled and can be re-enabled, the GitHub organisation membership is removed, and AWS does real IAM work — it creates users and, on offboarding, deletes login profiles, access keys, policy attachments and the user itself. Treat every step as live.
A Step That Can’t Complete Never Goes Quiet
If a provisioning step fails or falls back to a manual task — a hook is down, a provider can’t be reached — Zonitix raises it on three channels at once: a durable audit-log row, an in-app alert to IT, and an email when SMTP is configured. The first two never depend on mail being set up, so a silent failure can’t hide on a box with no outbound email. Each issue alerts once per step, so retries don’t spam.
The New Hire’s Temporary Password
When a run creates an account in Microsoft Entra ID, Active Directory or OpenLDAP, Zonitix generates a random temporary password that the person must change the first time they sign in. If email is set up and HR recorded a personal email address for the hire, the password is emailed to that personal address and the step shows only a masked confirmation. Otherwise the step offers Reveal password to a member of the queue that holds the run: it is shown once, then deleted. The reveal is recorded in the audit log; the password itself is never written there. The other providers do not hand back a password here.
If something here is not working as you expect, start with When something goes wrong.
The plain explanation is above. This part is for IT and developers: the exact settings, permission names, API addresses and data fields behind it. Closed: select the heading above to open it. While it is closed, your browser’s find-on-page (Ctrl+F or Cmd+F) does not search this part.
Orchestration Pipeline
The onboarding service uses an event-driven flow to trigger external API actions sequentially. The orchestration runner validates response codes before continuing to downstream steps.
| Onboarding Phase | API Call Target | What The Call Does |
|---|---|---|
| Directory Provisioning | Microsoft Graph API /users | POST /users creates an enabled account with a generated temporary password that must be changed at first sign-in. No licence is assigned. Group membership is added only by a separate Add to Directory Group step. On offboarding the account is disabled (PATCH accountEnabled=false), not deleted. |
| Workspace Setup | Slack Web API users.admin.invite | Sends a workspace invitation to the work email. No channels are joined. On offboarding the member is deactivated with users.admin.setInactive. |
| Developer Tools | GitHub API PUT /orgs/{org}/memberships/{login} | Adds the person to the organisation with the role member. No repository or team access is granted. On offboarding the organisation membership is removed (DELETE on the same path). |
Reveal password works once: a second request answers 410. The reveal is audited as TASK_CREDENTIAL_REVEALED; the password itself is never written to the audit log and is stripped from every other API response.
Triggering A Provisioning Run
There is no single “provision this employee” endpoint. A completed hire materialises an onboarding run, and IT drives it through the task API — either one step at a time, or by kicking off every currently-eligible automated step at once:
// Run every automated step that is currently eligible for this run:
POST /api/v1/user-management/tasks/:id/kickoff
// Or execute a single step:
POST /api/v1/user-management/tasks/:id/execute-node
Body: { "nodeId": "3" }
// Execution is queue-owned and idempotency-guarded: only a member of the
// task's current queue may fire it, and a double-submit cannot double-provision.