A workflow that provisions access correctly still needs someone to start it. Automated provisioning removes that last manual trigger, but the part worth understanding is exactly what replaces it, and how much control you keep once a human is no longer the one pressing run.
There's a meaningful difference between "provisioning can be automated" and "provisioning actually happens automatically."
A playbook proves the first: it's a reusable, correctly-built sequence, but someone still has to open it and run it. The second requires a separate layer that decides, on its own, when a playbook should fire and for whom, without a person remembering to start it.
That's what Zluri's automation layer, Automation Rules and Zero Touch Onboarding, is built to do. This piece covers that layer specifically: what triggers it, how precisely it can be scheduled, what happens when it's wrong, and how it stays auditable once nobody is manually clicking run.
The Engine Underneath: WHEN, IF, THEN
Automation Rules replace a manually launched playbook with a rule that fires on its own, built from three parts.
WHEN is the trigger, the event that activates the rule in the first place. For onboarding specifically, Zluri supports two:
- User is Marked for Onboarding: someone or something flagged this person as joining
- New User for an App Detected: Zluri's own discovery layer spotted a new user showing up in a connected application before any formal onboarding record existed for them
That second trigger matters more than it first appears. It means automated provisioning logic can catch and correct access even in cases where the formal HR process didn't fire first.
IF is the condition, filtering exactly who the rule applies to. This uses the same attribute logic as workflow conditions: standard fields like department and location, or custom fields specific to the organization, combined with AND/OR logic. A rule scoped to "Department = Sales" only ever touches sales hires. A rule with no condition at all applies to everyone matching the trigger.
THEN is the action, almost always running one or more playbooks. The same action step can also directly assign app access, execute a native Zluri action, or create a manual task without a full playbook behind it. Multiple playbooks can be sequenced within a single rule, with a Wait for x days option to deliberately space them out rather than firing all at once.
Put together: Emily joins Sales → WHEN a user is marked for onboarding → IF Department equals Sales → THEN run the Sales Onboarding Global Playbook. Her Salesforce, Zendesk, and Slack access provisions on day one with zero manual IT involvement, from the moment the rule is switched on.
Precision Timing, Not Just "Eventually"
A rule that fires the instant someone is marked for onboarding is useful. But real onboarding isn't a single moment, it's a sequence spread across days or weeks before and after a start date.
Zluri's scheduling layer handles that directly, at the level of each individual playbook action inside a rule, not just the rule as a whole. Each action gets its own timing setting:
- Immediately: fires as soon as the trigger condition is met, regardless of the actual onboarding date
- On onboarding date and time: fires exactly on the date recorded in the system, whether entered manually or synced from HR
- Before / After: fires a specified number of days ahead of or past that date
Each option carries its own execution time and timezone. Default execution time is 9:00 AM in the configured timezone, with IST, UTC, and US Eastern among the supported options.
This is what allows one rule to stage an entire onboarding sequence rather than dumping every access grant on day one: identity creation seven days before start, communication-channel access two days before, and full birthright access exactly on the onboarding date. Each is a separate playbook action inside the same rule, each with independent timing, and additional playbook actions can keep being added as the sequence grows more elaborate.
Two real limitations are worth knowing rather than discovering the hard way.
Scheduling is day-level only. There's no hour-level precision on Before/After timing.
Time Zone is set at the rule level, not per individual user. Approximating true local-time delivery across regions requires building separate rules per region, each conditioned on a synced attribute like Country, rather than one rule that adapts automatically per user.
Behaviors That Are Easy to Get Wrong
Automated provisioning removes a manual step, which also removes a natural checkpoint where a human might have caught a mistake. Three specific behaviors are worth knowing before anything goes live.
Rules are never retroactive. A rule only applies to users marked for onboarding after the rule itself is activated, even if a user's actual onboarding date is already set in the future at the moment the rule goes live. There's no quiet catch-up pass that reaches back and applies new logic to already-marked users.
Saving a rule does not activate it. Building and saving a rule is a distinct, separate step from switching its Status toggle to Active. Nothing fires until that toggle is deliberately flipped, which exists specifically so a half-configured rule can't start running by accident the moment it's saved.
Editing a live Automation Rule clears its current configuration entirely, and this can't be undone. There's no partial-edit path that preserves everything except the one setting being changed. Any rule already running in production should be reviewed carefully, and ideally discussed with whoever owns provisioning logic organizationally, before it gets touched.
Removing the Trigger Entirely: Zero Touch Onboarding
Automation Rules still depend on a user being marked for onboarding inside Zluri, by a person, an integration, or a synced HR event. Zero Touch Onboarding goes one step further and removes even that dependency.
It connects directly to the HR platform (HiBob, PersonioHR, BambooHR, and SDK-based integrations are supported) and treats the hire date already sitting in that system as the trigger itself. Setup requires working with a Customer Success Manager or Engineer to locate the exact hire-date field in the HR platform, since that field varies by system and configuration.
Two operational details matter once it's running:
- Zluri pulls hire dates once daily at 00:00 UTC, so a same-day edit in the HR system may not be reflected until the next cycle
- Each additional HRMS instance requires its own separate configuration. Zero Touch Onboarding doesn't automatically span multiple connected HR systems at once
One sequencing rule is easy to get backwards: the provisioning workflow has to be built and exist before the HRMS trigger is configured, not after. Configuring the trigger first, before there's a workflow for it to actually fire, is a setup order that doesn't work.
Once live, the mechanics mirror standard Automation Rules exactly: the same WHEN/IF/THEN structure, the same Immediately/On-date/Before/After timing options, just triggered by a hire date that HR never has to manually flag inside Zluri at all.
The ITSM Variant: Zero Touch Onboarding via Jira
For organizations that route access requests through an ITSM tool rather than directly through HR, Zluri supports an equivalent automated flow anchored to Jira instead of an HRMS.
A user (or HR, on their behalf) submits an onboarding request as a Jira ticket. An approval workflow runs inside Jira. If approved, the request moves to Zluri; if not, Jira notifies the requester and closes the ticket without ever reaching Zluri.
Zluri then checks whether the user's profile already exists. If it does, the provisioning playbook triggers directly; if not, Zluri creates the profile first, then triggers the playbook.
On completion, Zluri writes a confirmation note back onto the original Jira ticket, and Jira closes it and notifies the requester, closing the loop without anyone needing to check two systems separately.
What Automated Doesn't Mean
It's worth being precise about what "automated" actually removes and what it doesn't.
Automation Rules and Zero Touch Onboarding both eliminate the manual trigger, the step where a person decides "start this now." Neither one removes the governance layers configured inside the playbooks and workflows they run.
A playbook action still requiring approval before executing still requires it. An automation rule that triggers that playbook doesn't bypass the approval gate, it just removes the need for someone to manually kick off the process that eventually reaches that gate.
Similarly, any action inside the triggered playbook that's configured as a manual task still becomes a manual task. Automation routes it to the right assignee automatically; it doesn't silently convert it into something it wasn't configured to be.
The automation layer changes who starts the process, not what governance the process itself enforces.
Staying Auditable Once Nobody's Clicking Run
Removing the manual trigger raises an obvious question: how do you know what actually happened, and why, after the fact.
Zluri answers this the same way for automated runs as for manual ones, through the same underlying Run Logs, with the trigger source explicitly recorded (Manual, Automation Rule, or Scheduled). Nothing about an automated run is any less traceable than something a person clicked through by hand.
The Automation Rules table itself adds a layer above that: every rule shows its current Status (Active/Inactive), a direct link to view its run history, and full Created At / Created By metadata.
Combined with Run Logs' per-action outcome tracking (Completed, Failed, Pending) and exportable audit history, an automated provisioning event carries exactly the same evidentiary weight in a SOX, HIPAA, or GDPR audit as a manually triggered one. The automation is a different starting mechanism, not a different, less-documented process.
Why This Matters Beyond Convenience
The value of automated provisioning isn't just saving IT a few clicks per hire. It's closing the specific gap that shows up when provisioning depends on a person remembering to act:
- A new hire idle on day one because nobody triggered the workflow in time
- Inconsistent access because two different admins built the onboarding sequence slightly differently
- A security-relevant access grant that happened days late because it was sitting in someone's queue
Automation Rules and Zero Touch Onboarding both exist to make sure the correct sequence fires at the correct moment regardless of whether anyone happened to be watching that day, while keeping every part of that sequence just as governed, approvable, and auditable as if a person had triggered it by hand.
Frequently Asked Questions
If I activate an automation rule today, will it apply to employees who are already marked for onboarding with a future start date?
No. Automation rules are never retroactive. Only users marked for onboarding after the rule is switched to Active are affected, regardless of whether their actual onboarding date is already scheduled in the future.
Does Zero Touch Onboarding still require someone to mark a user for onboarding inside Zluri?
No, that's specifically what it removes. It uses the hire date already present in the connected HR system as the trigger directly, rather than depending on a separate marking step inside Zluri.
Can automated provisioning skip an approval step that would normally be required?
No. Automation controls when a playbook is triggered, not what governance is configured inside it. If an action requires approval before it runs, that requirement still applies exactly the same way whether the playbook was started manually or by an automation rule.
What happens if I need to change one small setting on an automation rule that's already live?
Treat it carefully. Editing a live rule clears its entire existing configuration, there's no partial edit that changes one field while preserving the rest. Review the full rule before touching it, and consider rebuilding it fresh rather than editing in place if the change is significant.
.svg)
