Zluri's Access Management is built around Workflows, Playbooks, and Automation Rules that govern access across joiners, movers, and leavers. Here's what each component does and how they connect.
Most access management tools give you a way to run provisioning workflows. Zluri's Access Management module goes further: it's a connected system where Workflows, Playbooks, Automation Rules, conditional logic, and real-time intelligence all work together to govern access across every lifecycle event, joiners, movers, leavers, and the informal access that falls between all three.
This article walks through every component of Zluri's Access Management module: what it does, how it works, and how it connects to the rest of the system.
The Foundation: Source of Truth and Directory Management
Before any provisioning can happen correctly, Zluri needs accurate, real-time identity data. That starts with connecting to your source of truth, the authoritative system that holds employee attributes: name, role, department, designation, reporting manager, location, and employment status.
Zluri integrates with all major HRMS platforms (BambooHR, Workday, HiBob, Zoho Recruit, Freshteam) and identity providers (Okta, Azure AD, Google Workspace, Ping Identity). Directory Management in Zluri's settings controls which system provides which attribute, department from one source, designation from another, reporting manager from a third, and how users are categorized as employees or external (vendors, contractors, partners).
Sync timing matters. For BambooHR, Google Workspace, Azure AD, and Okta, Zluri syncs instantly via webhook: a field change in the HRMS propagates immediately. For all other integrations, the default cycle is 24 hours.
User Categorization is particularly important for external identities. Zluri classifies users as Employees or External based on email domain, primary source, or custom rules. This is what enables different Playbooks to run for full-time employees versus contractors. The system knows who is who before any provisioning begins.
Workflows: One-Time, Ad Hoc Provisioning
A Workflow is Zluri's mechanism for one-time, user-specific provisioning or deprovisioning. It's the starting point for any access change that doesn't fit a standard pattern: a single new hire with unusual requirements, an emergency access grant, a one-off offboarding for an edge case.
Every Workflow begins with user selection. Once users are selected and Continue is clicked, the Workflow builder opens, a two-panel interface where the control panel on the left shows an overview of configured actions and surfaced recommendations, and the canvas on the right is where App Blocks and Actions are built.
Applications are added via three methods:
- Searching by name
- Selecting from Recommended Apps, pre-suggested based on the selected user's role, department, and location
- Adding a Zluri Actions block for platform-level operations
Once configured, a Workflow can be run immediately, scheduled for a specific date and time, or saved as a Playbook for future reuse. Unfinished Workflows auto-save to Drafts. The Recent Runs tab shows execution status (completed, completed with errors, failed, or pending) without manual follow-up.
What this means in practice: A new senior engineer joining a specialized team might need a one-off Workflow that provisions a non-standard tool alongside the standard engineering stack. IT builds it once, runs it, and if the same pattern will repeat, saves it as a Playbook.
Playbooks: Reusable Templates for Standardized Provisioning
Where Workflows are one-time, Playbooks are reusable. A Playbook is a user-agnostic template: it defines the applications and actions without being tied to any specific person. The same Playbook runs for every new software engineer, every departing marketing manager, every employee transferring from Sales to Customer Success.
Playbooks are built in the same builder interface as Workflows, with one key difference: there's no user selection at creation time. The Playbook is configured once per role profile and applied to any matching user when triggered.
A Playbook must be Published before it can be triggered by Automation Rules. A "Setup Required" status means the configuration is incomplete, typically a missing parameter or unfulfilled prerequisite. The Publish button stays grayed out until everything is correctly configured.
Playbooks can be duplicated to create department or region variants without rebuilding from scratch. They can also be organized into folders for easier management across large libraries.
Staged provisioning via Playbooks: A single Automation Rule can chain multiple Playbooks with independent timing. Identity creation 7 days before the start date, channel access 2 days before, birthright application access on day one. The employee arrives already set up. The first-day experience reflects a team that prepared for them.
What this means in practice: Build a Playbook for each role profile. It runs for every employee in that role, automatically, without per-hire configuration. The engineering onboarding Playbook provisions GitHub with the correct repository access, Jira with the appropriate project board, and Slack with the team's channels, based on what the peer group actually uses.
Peer Group Intelligence and the Recommended Tab
Every time a user is selected in a Workflow or a Playbook is configured, Zluri's Recommended Tab surfaces contextual suggestions.
Before any app is added, it shows recommended applications based on what peers in the same role, department, and location actively use. Once an app is added, the same tab switches to showing recommended actions within that app: which Slack channels to add the employee to, which GitHub repositories, which Jira projects.
These recommendations come from peer group analysis, live usage data across the organization, not a manually maintained list that IT built once. A content writer joining marketing sees ProWritingAid, Grammarly, and Trello suggested because that's what the content team is running on. A new software engineer sees the specific repositories their team uses, not a generic GitHub invitation.
The same intelligence applies to the movers scenario. When an employee transfers to a new team, Zluri knows what tools and channels the destination team uses, and surfaces those for the provisioning side of the transition.
What this means in practice: IT doesn't need to research what each new role needs. The peer group data already knows. The employee arrives already in the right channels and groups, without their manager spending the first morning manually adding them to everything.
App Blocks, Actions, and Conditional Logic
Within each Playbook or Workflow, every application is represented as an App Block. Each App Block contains one or more Actions, the specific operations to perform within that application: add a user to a workspace, assign a license, invite to a channel, revoke access, set email forwarding.
Actions are organized into categories:
- ADD: grant access, assign licenses, add to groups
- DELETE: remove access, revoke licenses
- UPDATE: modify profiles, send notifications
- MANUAL: human-executed tasks
- ZLURI ACTION: platform-level changes
- SSO Actions: provisioning through the SSO layer
- CUSTOM ACTION: bespoke API-based operations
Two levels of conditional logic make a single Playbook capable of handling multiple user types and permission levels simultaneously.
Add Conditions (App Block level) gate whether the entire application runs for a given user. A GitHub block with the condition "User Current Department = Engineering" only provisions GitHub for Engineering users. Users in other departments skip the block entirely.
Apply Condition (Action level) gates whether a specific action within an App Block runs. Within the same GitHub block, Apply Condition on User Current Designation means a Software Engineer gets Triage access to specific repositories while an Engineering Manager gets Admin access to the organization. Both come from the same Playbook, with the correct scope applied automatically based on who is being provisioned.
The combination enables a practical pattern: one Playbook handles both full-time employees and contractors without duplication. Add Conditions gates the application on user status (inactive users get nothing, no unnecessary licenses). Apply Condition branches the actions: FTEs get added to all team channels; contractors get added only to the relevant project groups. A single conditional Playbook, zero maintenance overhead from managing two.
Four additional controls apply per action:
- Add Delay: schedule an action to execute minutes, hours, days, or weeks after the Playbook triggers. Send the welcome email one day after account creation. Assign advanced tools after a one-week probation period.
- Require Approvers: the action only runs after a designated approver reviews and approves it. Used for sensitive access like admin roles or expensive licenses.
- Break on Error: when enabled, a failure at this step stops the entire Workflow. When disabled, the Workflow continues past the failure. Configured per action; critical steps break on failure, independent or notification steps continue.
- Wait Until Completion: the next action waits for the current one to reach a terminal state before executing. Always ON for automated actions.
Automation Rules: The Event-Driven Engine
Automation Rules are what transform Playbooks from templates into a running system. They define when a Playbook should trigger automatically, based on lifecycle events and conditions, with no manual intervention required.
Every Automation Rule follows a three-part structure.
WHEN (Trigger): the lifecycle event that fires the rule.
- For onboarding: "User is Marked for Onboarding" or "New User for an App Detected"
- For offboarding: "User is Marked for Offboarding," "User is Removed from a Group," or "User is Archived"
- For movers: "User's Department Changes," "User's Designation Changes," "User's Reporting Manager Changes," "User's Status Changes," "User's Account Type Changes"
IF (Conditions): filters that determine which users the rule applies to. Department, designation, location, account type, role, previous department, employment type, combinable with AND/OR logic. This is what allows one rule to branch correctly: a contractor promotion gets a different Playbook than a full-time promotion; a UK-based engineering manager gets different provisioning than a US-based one.
THEN (Action): one or more Playbooks to run, each with its own timing. Four scheduling options:
- Immediately: fires as soon as the user is marked or the condition is met
- On onboarding/offboarding date and time: fires on the exact scheduled date
- Before: fires X days before the scheduled date, identity creation ahead of time
- After: fires X days after, useful for post-onboarding access escalation
Single rule for movers: A single Automation Rule can handle the full mover transition by running a deprovisioning Playbook for the old role, then using a Trigger Playbook action to launch the onboarding Playbook for the new role. Both sides run in sequence, from one rule, with a configurable Wait For delay between them for handoff periods. This eliminates the timing gap and access accumulation that comes from two independently-timed rules.
Region-based scheduling: Separate rules conditioned on Country or Region attributes, each with its own timezone, ensure Playbooks run at the correct local time for global teams.
Critical activation sequence: A rule must be saved AND activated (status toggled to Active) before it applies. Rules do not run retroactively; users marked before a rule is activated are not affected.
Offboarding Auto-Population
The offboarding module has one capability that exists nowhere else in the platform. When an offboarding Workflow is created for a departing employee, Zluri automatically scans their complete access footprint and pre-populates the Workflow with every application they have access to, including shadow IT and department-managed tools that never went through central IT procurement, along with suggested deprovisioning actions per app.
This is fundamentally different from a checklist. A checklist covers what IT already knows about. Auto-population covers what the employee actually has access to at that moment. For an employee who has been at the organization for three years and moved through two departments, the gap between those two lists can be significant.
The complete offboarding sequence Zluri handles:
- Access revoked from all devices and applications, including shadow IT
- Data backed up before license termination, so no data is lost when accounts close
- User license revoked across all applications
- SSO removed
- Account deleted, including cloud data
Different Playbooks handle different identity types. A Standard Employee Exit Playbook covers the full sequence for employees. A Contractor Exit Playbook handles the specific deprovisioning steps for external identities, with different actions and scope.
Run Logs and Scheduled Runs: Execution Visibility and Compliance Proof
Every time a Playbook runs, whether manually triggered, scheduled, or fired by an Automation Rule, Zluri records a complete log entry: which user, which Playbook, which actions, when each executed, who triggered it, and the outcome of each step.
Run status is one of four states:
- Completed: all actions succeeded
- Completed with Errors: some actions failed, others succeeded
- Failed: all actions failed
- Pending: awaiting a manual task or approval before the next step can proceed
For failed actions, two resolution paths exist. Retry Action re-executes the same configuration, for temporary failures like network timeouts. Convert to Manual Task assigns the failed step to a human task owner, for permanent failures like disconnected integrations.
Scheduled Runs are the future-facing view: every Playbook or Rule configured to execute at a future date and time, visible before they fire. After execution, they move to Run Logs.
Compliance proof: Onboarding Scheduled Runs provide a timestamp proving access started only from the employee's hire date. Offboarding Scheduled Runs provide a timestamp proving access ended immediately at exit. Both are exportable as CSV, one-time or on a recurring schedule (daily, weekly, monthly), sent automatically to compliance teams. This makes audit preparation a report run, not a reconstruction project.
Access Requests: Governing What Automation Can't Predict
HRMS-triggered Automation Rules handle role-based access reliably. They have no mechanism for event-based access: the project collaboration tool someone needs for three months, the temporary elevated permissions for a weekend deployment, the coverage access while a colleague is on leave.
Access Requests (also known as the Employee App Store) is the structured channel for this category. Employees submit requests through the App Catalog, a configurable, branded interface showing applications available in the organization, by department, or globally. Each request carries: the application, license type, app role, access duration, business justification, priority, and supporting documents.
Three request paths exist: from the Applications page, from the Overview dashboard, or via the /accessrequest Slack command.
When an employee requests an application not in the organization's stack, Zluri surfaces similar apps already in use, steering requests toward the governed inventory rather than introducing new shadow IT.
Automation Rules for Access Requests govern what happens after a request is submitted:
- Auto-Approve: for low-risk, frequently requested access. Triggers a Provisioning Playbook automatically, with an optional Deprovisioning Playbook for time-bound access that expires when the access period ends.
- Initiate Approval Process: routes to approvers, specific users, Zluri roles (App Owner, Reporting Manager), or user groups. Multi-level approval chains supported.
- Auto-Reject: for policy violations, restricted apps, or unauthorized access levels. Sends the rejection reason to the requester immediately.
These rules evaluate conditions (department, job title, location, app role, license type, access duration, risk score) and apply with AND/OR logic. App-specific rules take precedence over general fallback rules.
Approver Insights surface contextual intelligence at the point of decision:
- How many peers in the same role and department already have the app and the requested access level
- The requester's history with this specific app over the past 12 months
- The approval rate for peer requests
- Whether the access level is standard or privileged
A summary signal (Approval Recommended / Review Carefully / Potential Risk Detected) rolls all of this up at a glance. Approvers log which insights informed their decision alongside a free-text reason, creating a traceable record linking context to outcome.
For external users (vendors, contractors, and partners with no HRMS record), Access Requests with mandatory time-bound duration is the primary governance mechanism. When the engagement ends, access expires automatically, without a separate removal request.
Variables and Advanced Automation
For organizations running complex multi-step workflows, Zluri supports advanced mechanics that extend standard provisioning logic.
Variables are dynamic placeholders ({{user.first_name}}, {{user.department}}, {{user.user_reporting_manager_name}}) that automatically fetch user-specific data during execution. Welcome emails address the new hire by name. Slack messages include department-specific information. No hardcoding, no copy-paste errors.
Output Chaining captures the response from one HTTP or custom action and passes it as input to the next action. Fetch a user's system ID from their email, then pass that ID into a group assignment action. This enables multi-step automations where each step depends on the previous step's data.
Custom Actions are reusable API-based actions built within app blocks, using the app's existing OAuth credentials automatically. Created once, reused across Playbooks. For applications without native Zluri integrations, HTTP Request actions enable direct API calls, one-time, with manual credential configuration.
Zero Touch via Jira: For organizations using Jira as their ITSM, the full onboarding process can flow through Jira. HR logs an onboarding ticket, the approval flow runs in Jira, Zluri verifies the user, triggers the Playbook, provisions access, and updates the Jira ticket with a completion note. No separate IT action required.
How the Components Connect
The power of Zluri's Access Management module is in how these components work together rather than in isolation.
Directory Management provides the clean identity data that makes everything downstream reliable. Peer group analysis drives intelligent recommendations that reduce IT configuration overhead and improve the employee experience. Workflows handle exceptions; Playbooks handle the standard; Automation Rules connect the two to lifecycle events and fire them automatically.
Conditional logic means one Playbook can handle multiple user types and permission levels without duplication. Offboarding auto-population closes the coverage gap that checklists leave open. Access Requests with Approver Insights governs what HRMS automation can't reach. Run Logs and Scheduled Runs generate compliance evidence as a byproduct of operations.
Together these components form a lifecycle system that runs continuously. Not a tool that IT has to remember to use, but a process that fires when the condition is met, every time, for every employee.
Frequently Asked Questions
What is Zluri's Access Management module?
Zluri's Access Management module is the component of Zluri's IGA platform that automates provisioning and deprovisioning across the full employee lifecycle (joiners, movers, and leavers) for both federated and unfederated applications. It includes Workflows, Playbooks, Automation Rules, conditional logic, offboarding auto-population, Access Requests with Approver Insights, Run Logs, and Scheduled Runs.
What is the difference between a Workflow and a Playbook in Zluri?
A Workflow is a one-time, user-specific sequence of steps, built for a specific person or a one-off scenario. A Playbook is a reusable, user-agnostic template, configured once per role profile and applied to any matching user when triggered by a rule or run manually. Workflows can be saved as Playbooks. Playbooks must be Published before Automation Rules can trigger them.
How does Zluri know what apps to recommend for a new hire?
Zluri's peer group analysis continuously maps what tools each team, department, and seniority level actually uses. When a new hire is selected in the Workflow builder, the Recommended Tab surfaces applications based on real usage data from peers in the same role, department, and location, not a manually maintained list. The same intelligence extends inside applications, recommending which Slack channels, GitHub repositories, and Jira projects to add the employee to.
Can a single Automation Rule handle both sides of a role transition?
Yes. A single Automation Rule 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, from the same HRMS field change event. A configurable Wait For delay between the two steps provides a bounded handoff window.
What happens when an offboarding Workflow is created in Zluri?
Zluri automatically scans the departing employee's complete access footprint and pre-populates the Workflow with every application they have access to, including shadow IT and department-managed tools, with suggested deprovisioning actions per app. IT doesn't need to recall or maintain an inventory of what the employee can access. Zluri builds it at offboarding time.
How does Zluri handle access requests for tools outside the standard provisioning profile?
Access Requests (also known as the Employee App Store) provides a structured self-service channel. Employees submit requests with business justification, license type, app role, and access duration. Automation rules determine whether the request is auto-approved, routed to approvers, or auto-rejected based on policy. Approvers see contextual insights (peer adoption, request history, access level) to inform decisions. Time-bound access expires automatically on the set date.
How does Zluri generate compliance evidence?
Every Zluri action generates a timestamped log entry with full attribution. Onboarding Scheduled Runs prove access started only from the employee's hire date. Offboarding Scheduled Runs prove access ended at exit. Run Logs can be exported on a recurring schedule to compliance teams. This data supports SOC 2, ISO 27001, HIPAA, SOX, and GDPR audit requirements without manual evidence gathering.
.svg)
