Most automated provisioning still depends on someone marking a person for onboarding inside the platform. Zero Touch Provisioning removes even that step, triggering directly off a hire date already in the HR system or an approved ITSM ticket. This covers every setup requirement, configuration step, and real operational limit. (For the broader case behind this feature, see our guide to zero-touch provisioning as a concept.)
Zero Touch Provisioning is the most complete expression of removing manual steps from access provisioning. No admin has to launch a playbook, and no admin even has to mark someone for onboarding inside Zluri in the first place.
The trigger is something that already exists elsewhere: a hire date recorded in an HR system, or an approved ticket in an ITSM tool. Zluri acts on it directly. This piece covers both the HR-triggered version and its Jira-triggered counterpart.
What Zero Touch Actually Removes
It's worth being precise about what step this specifically eliminates, since it's easy to conflate with general automation. A standard Automation Rule still requires a person to be marked for onboarding, by an admin, an integration, or a synced event, before the rule's WHEN/IF/THEN logic can fire. Zero Touch Provisioning removes that marking step entirely. It connects directly to the HR platform and treats the hire date already sitting there as the trigger itself, with no separate action inside Zluri required to set that trigger in motion.
Supported HR Platforms
Zero Touch Provisioning connects to HiBob, PersonioHR, and BambooHR directly, along with SDK-based integrations for platforms not natively supported out of the box. This isn't a universal connection to any HR system automatically; it requires one of these specific supported paths to actually function.
Setup Requirements Before Anything Else
Configuring Zero Touch requires working directly with a Customer Success Manager or Customer Success Engineer. It isn't a fully self-service setup. Three prerequisites need to be in place before configuration can proceed:
The Setup-Order Requirement That Trips People Up Most
This is worth calling out as its own point, because it's the single most common configuration mistake. The workflow has to exist before the HRMS trigger gets configured, not after. Configuring the trigger first, before there's an actual workflow for it to fire, doesn't work. The order isn't a best-practice suggestion; it's a functional requirement of how the setup process actually works.
Configuration Steps, in Order
- Locate the specific hire-date field in the HR platform, and share it directly with the assigned CSM or CSE, since this varies by system and by how a given organization's HR instance is configured.
- Navigate to Workflows → Onboarding (or Offboarding, for the equivalent departure-triggered flow) → Automation Rules → + New Rule.
- Set the WHEN trigger to User is Marked for Onboarding.
- Set the IF condition to User Account Type equals Employee.
- Choose the onboarding playbook under THEN, along with a scheduling trigger:
- Immediately: fires as soon as marked, regardless of the actual date, applying only to profiles marked after activation
- On onboarding date and time: fires exactly on the HR-system date and time, in the configured timezone, also only for profiles marked after activation
- Before / After: fires a set number of days ahead of or past the date, at a custom time and timezone
- Save Rule, then separately activate it, since saving alone does not turn the rule on. Once active, Zluri uses the HR system's hire date to trigger the configured onboarding actions automatically.
Real Operational Limits Worth Knowing
Several specific constraints matter enough to state directly rather than discover later.
The Jira-Triggered Variant
For organizations routing onboarding requests through an ITSM tool rather than directly through HR, an equivalent Zero Touch flow runs off Jira instead of an HR system's hire date.
The sequence:
- A user submits an access or onboarding request as a Jira ticket.
- An approval workflow inside Jira evaluates it.
- If not approved: Jira notifies the requester and closes the ticket. Zluri is never involved.
- If approved: the request moves to Zluri, which checks whether the user's profile already exists.
- If it does, the relevant provisioning playbook triggers directly.
- If it doesn't, Zluri creates the profile first, then triggers the playbook, so a request for someone not yet fully onboarded doesn't fail on that basis alone.
- On completion, Zluri writes a confirmation note directly onto the originating Jira ticket, and Jira closes it and notifies the requester, closing the loop entirely within the same ticket the process started on.
Setting this up requires:
- Jira configured as the actual source of truth for onboarding requests specifically
- The relevant applications already integrated with Zluri
- Three specific API calls available: Trigger Playbook, Create User, and Get or Verify User Profile
On the Jira side, this is built as an Automation rule with an event trigger, condition validation, and a web request action checking whether the user exists in Zluri. A 200 response triggers the playbook directly; a 400 response creates the user first via a separate web request before triggering it; a final web request on success sends a notification and updates the ticket.
Why the HR-Triggered and Jira-Triggered Versions Solve the Same Problem Differently
Both variants remove the same manual step: someone marking a person for onboarding inside Zluri directly. What differs is which system they trust as the source of truth.
The HR-triggered version fits organizations where the HR system's hire date is the earliest, most authoritative signal that someone is joining.
The Jira-triggered version fits organizations where access requests and onboarding already flow through an existing ITSM process as the real system of record. HR data may enter the picture later, or through a separate path entirely.
Neither is more "zero touch" than the other. Both are the same underlying idea, anchored to whichever system an organization actually treats as authoritative. For the wider set of provisioning mechanics this connects to, see how Zluri automates provisioning.
Frequently Asked Questions
Can Zero Touch Provisioning be configured entirely without help from Zluri's team?
No. Setup requires working with a Customer Success Manager or Customer Success Engineer specifically, since locating the correct hire-date field and configuring the connection correctly isn't a fully self-service process.
What happens if someone updates a new hire's start date in the HR system the same day the change is needed?
It may not take effect immediately. Zluri pulls hire dates once daily at 00:00 UTC, so a same-day edit might not be reflected until the following day's sync, which is worth factoring into any last-minute date changes.
Does activating a Zero Touch rule apply retroactively to people already marked with a future onboarding date?
No. Automation triggers configured this way only apply to profiles marked for onboarding after the rule is actually activated, even if a specific profile's onboarding date is already scheduled for some point in the future at the moment the rule goes live.
If an organization runs both an HR system and an ITSM tool, can it use both Zero Touch variants at once?
Yes. They're not mutually exclusive, since they anchor to different trigger sources for different populations or processes. An organization could use the HR-triggered flow for standard new-hire onboarding and the Jira-triggered flow for a separate ITSM-driven access request process, depending on which system is actually authoritative for a given scenario.
.svg)
