Zluri automates the complete JML lifecycle — joiners, movers, and leavers — with mechanics no other platform offers. Here's how it works and what makes it different.
The standard pitch for user lifecycle management software is automation: stop doing things manually, start doing them with workflows. Most platforms deliver on that pitch at a basic level. New hire gets provisioned. Departing employee gets offboarded. Tickets get eliminated for standard cases.
What separates Zluri from the rest isn't that it automates the lifecycle. It's how it automates the lifecycle — the specific mechanics it brings to each phase that other platforms either don't have or can't match.
This article covers how Zluri handles the full JML lifecycle end to end, and then gets into nine capabilities that are genuinely distinctive: things Zluri does that competitors either partially implement, handle differently, or don't offer at all.
How Zluri Automates the Full JML Lifecycle
Zluri's Access Management module is the operational core of its IGA platform. It governs all three phases of the employee lifecycle — Joiners, Movers, and Leavers — through a connected system of Playbooks, Automation Rules, and directory integrations.
Joiners: Provisioning From the HRMS Event, Not the Ticket
When a new hire record is created in the connected HRMS, Zluri detects the event and fires the appropriate onboarding Playbook automatically. No ticket required. No IT admin manually interpreting a provisioning request and deciding which applications it means.
The Playbook for that role provisions the full onboarding stack: every application the role requires, at the correct permission level within each application, with the employee added to the right Slack channels, project boards, and GitHub repositories as part of the same workflow. Recommendations are driven by peer group analysis — Zluri knows what tools each team, department, and seniority level actually uses, so the suggested stack reflects real usage rather than a manually maintained list someone built once.
Provisioning can also be staged before the start date: identity creation days in advance, channel access shortly before, full application access on day one. The employee arrives already plugged in — in the right channels, part of the right groups, with access to the tools their colleagues use. The first-week experience of discovering missing tools through conversations doesn't happen.
For BambooHR, Google Workspace, Azure AD, and Okta, sync is instant via webhook. For other HRMS integrations, the default cycle is 24 hours. The "Recent Runs" tab shows whether each onboarding completed, failed, or is pending — without manual follow-up from IT.
Movers: Both Sides of Every Transition in One Rule
When an employee changes roles, departments, or locations, the HRMS field change fires an Automation Rule. That rule runs a deprovisioning Playbook for the old role and then triggers the onboarding Playbook for the new role — both sides in one automated sequence, triggered by the same event, with a configurable delay between them if the employee needs a handoff window.
Permission levels within applications are recalculated based on the user's current designation at execution time. Not "GitHub continues" but "GitHub at the correct scope for the new role" — automatically, without a manual permission update.
Leavers: Discovery-First Offboarding
When an offboarding workflow is created for a departing employee, Zluri scans the employee's complete access footprint and pre-populates the workflow with every application they have access to — including shadow IT and tools outside the central IT inventory — with suggested deprovisioning actions per app.
The offboarding sequence covers access revocation across all devices and applications, data backup before license termination, device retrieval where integrated, license revocation, SSO removal, and full account deletion including cloud data. Every step runs from one automated workflow. Every step is logged.
That's the baseline. Now here's what makes Zluri different.
9 Things Only Zluri Does
1. Offboarding Auto-Population From the Full Access Footprint
Every other platform starts offboarding from a list. IT maintains an inventory of managed applications, and the offboarding workflow covers that list. For any application outside the inventory — shadow IT, department-managed tools, apps from previous roles — the platform has nothing to say.
Zluri inverts this. When an offboarding workflow is created, Zluri scans the departing employee's actual access footprint at that moment and builds the workflow from what it finds. The list isn't what IT already knew about. The list is what the employee actually has access to.
This is the only offboarding approach that reliably covers shadow IT and historical access accumulation. A platform that starts from an inventory will always have gaps wherever the inventory is incomplete. A platform that starts from discovery closes those gaps by definition.
The auto-population is exclusive to offboarding by design. New employees have no prior access history for Zluri to scan. The feature exists precisely for departures, where the accumulated access footprint is the risk.
2. Single Automation Rule for the Full Mover Transition
Most platforms handle movers with two separate rules: one offboarding rule to remove old-role access, one onboarding rule to add new-role access. The two rules fire independently, may have different timing, and depend on correct configuration of both to execute in the right order.
Zluri handles the full mover transition in a single Automation Rule. Within one rule:
The WHEN trigger fires on the HRMS field change (department, designation, reporting manager, location, account type).
The THEN action runs a deprovisioning Playbook for the old role, then uses a "Trigger Playbook" action to launch the onboarding Playbook for the new role.
The "Wait For" field sets a configurable delay between the deprovisioning and provisioning steps — giving the employee a bounded handoff window before old-department access disappears.
Both sides of the transition are governed by the same rule, the same event, the same audit log entry. There's no timing gap between them that produces an unintended access state. There's no risk of one rule running without the other.
3. Permission-Level Provisioning via Apply Condition
Provisioning at the application level means the user gets access to the application. Provisioning at the permission level means the user gets the correct scope within the application, calculated from their current role at execution time.
Zluri's Apply Condition feature provisions at the permission level. Within a single App Block for GitHub, for example:
A Software Engineer gets Triage access to the team's specific repositories (QuantumCoders24/BinaryForge, QuantumCoders24/InfiniteLoopers).
An Engineering Manager gets Admin access to the QuantumCoders24 organization, plus access to additional repositories their team owns.
Both are provisioned from the same Playbook. Apply Condition reads the user's current designation at execution time and applies the correct scope for that designation automatically. When the Software Engineer is promoted to Engineering Manager, the promotion triggers the Playbook again and the correct scope is applied for the new role — not inherited from the previous provisioning.
No other platform in the market does this with the same granularity and the same connection to the live designation field. Competitors provision at the application level and leave permission configuration as a manual step.
4. Dual Condition System: App-Level and Action-Level
Zluri has two distinct layers of conditional logic that operate independently and can be combined.
Add Conditions operates at the App Block level. It determines whether the entire application runs for a given user. A GitHub App Block with Add Condition "User Current Department = Engineering" means users outside Engineering don't receive any GitHub access at all when the Playbook runs.
Apply Condition operates at the Action level within an App Block. It determines whether a specific action within an application runs for a given user, regardless of whether the App Block itself is running. A Salesforce App Block with Apply Condition "User Current Role = Manager" on the "Create Group" action means all Sales team members get Salesforce access (App Block runs for all), but only Sales Managers get a group created (Apply Condition gates that specific action).
The combination is what makes genuinely granular governance possible:
Salesforce runs for all Sales users (Add Conditions: department = Sales).
Within Salesforce, standard provisioning runs for all Sales users (no Apply Condition).
Within Salesforce, the Manager role assignment runs only for Sales Managers (Apply Condition: role = Manager).
This two-layer architecture means a single Playbook can handle the full range of access patterns for a department — not a separate Playbook per role variant.
5. Configurable "Wait For" Delay With Automatic Execution
When an employee changes roles, some transitions need a handoff window. The employee needs to close out pending tickets, brief a successor, or finish work mid-project before their old-department access disappears.
Zluri's "Wait For" field in Automation Rules sets a delay in minutes, hours, or days before the next Playbook in the sequence triggers. The delay is applied before the Playbook runs, not after — so when the clock starts, access is still intact. When it expires, the Playbook fires automatically.
This is meaningfully different from a manual delay (setting a reminder to run the removal later) and from no delay (removing access at the moment the rule fires). It's a bounded window with an automatic end, governed by the rule configuration, not by human memory.
The same mechanism applies at offboarding: urgent separations can be triggered immediately; planned departures can be scheduled for the exit date. Both paths run automatically from the scheduled point.
6. Access Requests (Employee App Store) With Time-Bound Access Duration
The Employee App Store is Zluri's structured channel for access requests that fall outside standard role-based provisioning. It handles the category of access that HRMS-triggered automation can't govern: project access, cross-functional collaboration tools, temporary elevated permissions, coverage access.
What makes Access Requests distinctive isn't the request flow itself — most platforms have some form of access request. It's two specific mechanics:
Alternative app surfacing. When an employee requests an application that isn't in the organization's stack, Zluri shows similar applications already in use. The employee can choose an existing alternative instead of adding new shadow IT. The request stays within the governed inventory without requiring IT to manually redirect every unfamiliar request.
Time-bound access duration at approval. The approver sets an access duration when approving the request. Time-bound access expires automatically on the set date — no separate removal request, no dependency on someone remembering to follow up. The ending is built into the grant at the moment it's made.
The Changelogs tab records every modification or substitution an approver makes to a request, maintaining a complete audit trail for every access decision made through the Employee App Store, not just the ones that went through standard provisioning.
Access Requests is also the primary governance mechanism for external users — vendors, contractors, consultants, and partners who have no HRMS record and therefore no automatic lifecycle trigger. Every access grant to an external user should go through Access Requests with a time-bound duration tied to the contract or engagement period. When that period ends, access expires automatically, without a separate removal request or the risk of stale contractor credentials persisting indefinitely.
7. "Trigger Playbook" Action for Cross-Module Chaining
Zluri's "Trigger Playbook" action allows any workflow — onboarding, offboarding, or standalone — to launch another Playbook as a downstream action. This is what enables the single-rule mover handling described above, but it has broader uses beyond movers.
An access request approval can trigger a Playbook that provisions the approved access automatically, rather than generating a manual task.
An offboarding Playbook can trigger a separate data backup Playbook before the deprovisioning sequence begins, ensuring data handling happens in the right order.
A role change can trigger a notification Playbook that alerts the new manager, the old manager, and the employee simultaneously, as a built-in step in the transition sequence.
Cross-module chaining means complex multi-step identity workflows can be built from reusable components rather than monolithic single-purpose rules. Each Playbook handles one part of a larger sequence. The "Trigger Playbook" action connects them.
8. Break on Error With Selective Workflow Control
When a step in a provisioning or deprovisioning sequence fails — a network issue, a credential error, an integration timeout — most platforms either stop the entire workflow or continue past the failure regardless. Neither is always right.
Zluri's Break on Error toggle is configurable per action within a workflow. When enabled on a specific action, a failure at that step halts the workflow immediately. When disabled, the workflow continues past the failure to complete the remaining steps.
This matters because different actions have different failure consequences:
Breaking on the "Create User Account" action is correct: if the account doesn't exist, nothing downstream can work.
Continuing past a "Send Welcome Slack Message" failure is correct: a failed notification shouldn't block the employee's access to every other application.
IT teams configure Break on Error based on the dependency structure of each workflow — not as a global setting applied uniformly. The result is workflows that stop when stopping matters and continue when continuing is safe.
Failed actions with Break on Error enabled generate a Retry Action option, allowing IT to re-execute the specific failed step with the same configuration once the underlying issue is resolved, without rebuilding the workflow.
9. Peer Group Intelligence and In-App Suggestions
Most ULM platforms provision applications based on a role definition that an IT admin built manually. When that definition is stale, or when it never captured the nuance of what the team actually uses, new employees get the wrong stack — or an incomplete one.
Zluri's recommendations are driven by peer group analysis. The platform continuously maps what tools each team, department, and seniority level actually uses. When a new hire is selected in the workflow builder, recommended apps surface dynamically based on their specific profile — not a generic role template, but what real peers in that role are actively running.
This intelligence extends inside applications too. The Recommended Tab in the workflow builder doesn't just suggest apps. Once an app is added, it switches to showing recommended actions within that app — which Slack channels to add the employee to, which GitHub repositories, which Jira projects — based on what others in the same team are already part of.
The result for the employee: they don't spend their first week asking "which channels should I join?" or discovering tools through conversations. They arrive already integrated into the team's working environment. The result for IT: no manual research required to figure out what each new role needs. The peer group data already knows.
This same intelligence applies to movers. When an employee transfers to a new team, Zluri knows what tools the destination team uses and can surface those automatically for the provisioning side of the transition.
The Architecture Behind These Capabilities
These eight mechanics don't exist in isolation. They're built on three platform layers that make them possible:
Directory connectivity: Zluri connects to all major HRMS platforms (BambooHR, Workday, HiBob, Zoho Recruit, Freshteam) and identity providers (Okta, Azure AD, Google Workspace, Ping Identity) with continuous sync. Instant webhook sync for the four major IdPs means role changes propagate immediately. The "one user, one identity" principle ensures every access decision is made from a single accurate record, not from fragmented directory data.
Application coverage: 300+ integrations with 1,500+ granular workflow actions. The Universal Identity Connector extends coverage to ERPs, internal tools, database-backed systems, and legacy infrastructure through five pathways: Directory Integration, Enterprise Connectors, Database Orchestration, Extensible Connector Framework, and Interface Automation. Standard integrations deploy in 2–4 weeks; enterprise connectors in 4–8 weeks.
Visibility layer: Zluri's IRIS (Identity Risk Intelligence System) surfaces orphaned, dormant, external, and restricted access continuously. IVIP (Identity Visibility and Intelligence Platform) monitors human and non-human identities across directories, SaaS, and cloud. Risk and threat scores are assigned per application. Unauthorized applications surface automatically — not only at audit time, but as a continuous feed.
The nine capabilities described above work because this infrastructure is in place. Auto-population works because IVIP has already mapped the access footprint. Single-rule movers work because HRMS sync is instant and reliable. Permission-level provisioning works because 1,500+ granular actions exist across the integration library.
Run Logs feed compliance directly: every provisioning and deprovisioning action is timestamped, attributed, and exportable on a recurring schedule to compliance teams. Onboarding Scheduled Runs prove access started only from the hire date. Offboarding Scheduled Runs prove access ended at exit. For SOC 2, ISO 27001, HIPAA, SOX, and GDPR, this is evidence generated as a byproduct of normal operations — not reconstructed from email chains when an auditor asks.
What This Means for IT Teams
The operational difference between Zluri and a standard ULM platform shows up in three places:
Coverage at offboarding. A checklist-based offboarding misses what's not on the checklist. Zluri's auto-population doesn't have that limitation. Every departure is a complete offboarding, not an approximate one.
Access creep prevention. Single-rule mover handling with both-sided execution means every role transition removes old access at the same time it adds new access. Access creep doesn't accumulate because the removal side is never optional or separately timed.
Permission accuracy. Apply Condition means the right scope within each application is calculated at execution time from the current designation. There's no "provisioned correctly initially, drifted since" problem. Each provisioning event applies the correct level for the current role.
Employee experience. Peer group intelligence means new employees arrive with the tools their team actually uses, already added to the right channels and groups. The first-day experience isn't "wait for IT" — it's productive from hour one.
Together these close the gaps that produce the most access risk and the most operational friction in practice: incomplete offboarding, accumulated mover access, overprivileged permission levels, and poor day-one experiences that generate shadow IT workarounds.
Frequently Asked Questions
How does Zluri handle user lifecycle management differently from legacy IGA platforms?
Legacy IGA platforms (SailPoint, Saviynt) are architected for on-premises and hybrid infrastructure. They have deep capabilities for AD governance and complex regulatory environments, but implementation takes 6–12 months and requires dedicated IGA engineers. Zluri is purpose-built for modern SaaS environments: faster to deploy (weeks, not months), designed for IT administrators rather than specialist IGA teams, and built with capabilities like offboarding auto-population and single-rule mover handling that reflect how SaaS-native access management actually works.
What is offboarding auto-population and why does it matter?
When an offboarding workflow is created in Zluri, the platform automatically scans the departing employee's complete access footprint and pre-builds the workflow with every application they have access to, including shadow IT and tools outside the central IT inventory. This matters because any offboarding approach that starts from a pre-maintained list will miss applications not on that list. Starting from discovery means coverage is complete regardless of how the employee accumulated their access.
What is the difference between Add Conditions and Apply Condition in Zluri?
Add Conditions operates at the App Block level: it determines whether the entire application runs for a given user in a Playbook. Apply Condition operates at the Action level within an App Block: it determines whether a specific action within an application runs for a given user. The two can be combined in the same Playbook to produce granular governance — the right users get the right application, and within that application, the right users get the right permission level.
Can Zluri handle both sides of a role transition in a single rule?
Yes. A single Automation Rule in Zluri can run a deprovisioning Playbook for the old role and then use a "Trigger Playbook" action to launch the onboarding Playbook for the new role, in sequence, triggered by the same HRMS field change. A "Wait For" delay between the two steps provides a bounded handoff window. This eliminates the timing gap between old-access removal and new-access provisioning that two independent rules create.
What happens when a step in a Zluri workflow fails?
Each action in a Zluri workflow has a configurable Break on Error toggle. When enabled, a failure at that step halts the entire workflow immediately. When disabled, the workflow continues past the failure to complete remaining steps. IT teams configure this per action based on the dependency structure of the workflow: critical foundational steps break on failure; independent or notification steps continue. Failed steps with Break on Error enabled generate a Retry Action option to re-execute once the underlying issue is resolved.
How does Zluri prevent access creep?
Zluri prevents access creep structurally through single-rule mover handling: when an HRMS field change fires a role transition, the same Automation Rule that provisions new-role access also runs the deprovisioning Playbook for the old role. Both sides execute from the same event, at the same time, in the same logged sequence. There's no separate removal ticket that may or may not get filed. The removal is not optional and not separately timed. Over time, this means identities hold only the access their current role requires, not the accumulated access of every role they've ever held.
What is the Employee App Store (Access Requests) in Zluri and how does it handle event-based access?
The Employee App Store is Zluri's self-service channel for access requests outside the standard provisioning profile. Employees submit requests with a business justification; requests route to the appropriate approver; the approver sets an access duration at approval. Time-bound access expires automatically on the set date. If an employee requests an application not in the organization's stack, Zluri surfaces similar applications already in use, steering requests toward the existing governed inventory rather than adding new shadow IT.
.svg)
