Access management sounds like a single feature until you actually build one: granting access is a different problem than updating it, which is different again from revoking it, and all three need to work identically whether the target application has a full API or none at all. This piece goes inside the module that handles all three, at the level of detail an admin actually building in it needs.
Zluri's Access Management module, part of its IGA product alongside Access Requests, Access Reviews, and Segregation of Duties, has a complete overview covering how every component works and connects: the source-of-truth foundation, workflows versus playbooks, action categories, conditional logic, automation rules, peer group intelligence, offboarding auto-population, access requests, and run logs.
This piece deliberately repeats none of that. It's the companion one level deeper, covering what the overview doesn't have room for:
- The builder's anatomy, walked through a real build
- What the action categories actually contain for a real application
- How conditions and executions behave when they fail
- The production constraints on playbooks and output chaining
- The credential models behind custom automation
- The task layer that keeps non-automatable steps just as auditable as automated ones
If the overview answers "what does the module do," this answers "what exactly happens when I build in it." And for the layer above both, which access management problems this solves and why they matter, there's how Zluri solves user access management problems.
Anatomy of the Workflow Builder, Through a Real Build
The overview describes the builder's two-panel structure. What it can't show is how the parts behave in sequence during an actual build. So here's one: IT building a standard onboarding sequence for new Sales hires.
They start on the Overview tab. It's empty at first, with a single prompt to add a recommended action, which routes straight into the Recommended tab. There, Zluri suggests the applications a Sales hire in that location typically needs: Salesforce, a dialer tool, a specific Slack channel, each with a one-click + Add.
As soon as the first app lands on the canvas, that same Recommended tab switches roles. Instead of "here are apps you might want," it now shows "here are the actions available for the app you just added," with a running list of what's already been configured marked ✅ Added. The admin always has a clear view of what's covered and what's still missing.
The remaining three tabs each earn their place at a specific moment:
- Settings is where the workflow gets a real name, "Sales Onboarding, US" rather than a generic default, so it's identifiable later
- Runs stays empty until the workflow executes at least once, then becomes the place to check whether a specific hire's provisioning actually completed
- Help is there for exactly the moment someone building this for the first time gets stuck on a specific step
On the canvas itself, the Top Menu shows the draft is auto-saving as work happens, so nothing is lost if the admin gets pulled away mid-build. The User Menu shows exactly who this specific run applies to, with + Add More if a second hire needs the identical sequence.
Two builder behaviors matter that no component list mentions.
The same app can be added more than once, with different configurations each time. Searching "Slack" and adding it twice in the same workflow, once configured to add the person to #general and once to add them to #sales, is entirely supported. That's exactly how a real Sales onboarding sequence ends up looking: one Slack block for company-wide access, a second for the team-specific channel, both in the same workflow rather than needing two.
Some applications return multiple variants when searched. Okta's full integration with automated actions versus a web-based variant limited to manual tasks, for instance. These are genuinely different entries with different capabilities, not two labels for the same thing. Picking the right one determines whether that specific block can actually automate anything.
What the Action Categories Actually Contain
The overview lists the seven action categories (Add, Delete, Update, Manual, Zluri Action, SSO Actions, Custom). What the category names don't convey is the depth inside each one for a real application, and that depth is what makes a workflow capable of more than the obvious join-or-leave cases.
For Slack specifically:
- The Add group includes adding the person to the workspace, creating a channel, inviting them to a specific channel, adding them to a group, and updating their title, seven distinct actions covering everything a genuine onboarding sequence needs from that one application
- The Update group covers a different kind of moment entirely: marking reminders complete, updating a user's status, sending a message to a channel, useful for something like a mid-tenure title change that has nothing to do with someone joining or leaving at all
- The Delete group, used during offboarding, covers removing someone from every group, every channel, and deactivating their account, seven of its own distinct actions specifically for cleanly closing out access rather than granting it
One category deserves a concrete scenario, because its value is easy to miss from the definition alone.
SSO Actions matter specifically when access should cascade from a group assignment at the identity-provider level rather than being configured inside each downstream application individually. Adding someone to a security group in Okta that several connected applications already trust is one action. Provisioning each of those applications one at a time is many.
How Conditions and Executions Behave When They Fail
The overview covers the two condition levels (Add Condition at the app-block level, Apply Condition at the action level), their AND/OR logic, and the patterns they enable. What it doesn't cover is failure behavior, which is exactly what determines how a partially matching user moves through a workflow.
An app-level condition failing skips the whole block. The workflow moves on to the next application.
An action-level condition failing skips just that one action. The rest of the block continues.
The distinction decides, for instance, whether a contractor flowing through an employee-heavy playbook silently skips entire applications or receives an application with a subset of its actions.
The two execution controls have the same property: their definitions are simple, and the judgment call is in the scenario.
Wait Until Completion is always on for automated actions. If granting Salesforce access is the third step, the fourth won't fire until Salesforce actually confirms the third succeeded. Order is enforced by confirmation, not by hope.
Break on Error is a per-action judgment about what a failure should cost. Off (the default) is right for something low-stakes: an optional Slack channel invite failing shouldn't block everything else in someone's onboarding. On is right for the opposite case: access to a shared drive containing sensitive financial data failing silently, while the rest of onboarding continues anyway, is exactly the gap worth halting the whole sequence and alerting someone over.
Playbook Constraints That Only Matter in Production
The workflow-versus-playbook model, publishing, folders, and duplication are covered in the overview. Three operational constraints sit underneath that only start mattering once playbooks are live.
Drafts persist indefinitely. A workflow that isn't run, saved as a playbook, or scheduled auto-saves to a Drafts tab, triggered by navigating away, a session timeout, or simple inactivity. It stays there until deleted or converted. Nothing built gets silently lost.
Published playbooks have no live-edit path. Editing one always requires Unpublish and Edit, then republishing. That's a deliberate friction point against changing logic underneath a playbook mid-run.
Playbooks can call other playbooks, with one hard boundary. A Trigger a Playbook action lets shared logic live in one playbook and be reused across onboarding, offboarding, access requests, and access reviews without duplication. The boundary: this can't cross into or out of App Automation playbooks, which can't trigger, or be triggered by, the workflow-side playbook types.
The Exact Rules Behind Variables and Output Chaining
The overview introduces variables and output chaining as capabilities. Here are the mechanics and constraints that govern them in practice.
Variables have three inbound object types. Beyond standard user attributes ({{user.first_name}}, {{user.department}}), three object types can feed variables into a playbook specifically through the Trigger a Playbook action:
- Access Request data: role, license, user ID
- Access Review data: reviewer, action, comment
- Generic Text data from an external system: an ITSM ticket ID, for instance, letting a playbook update that same ticket automatically once provisioning completes
The Variables tab itself requires enablement by a Customer Success Manager.
Output chaining carries three constraints worth knowing before designing around it:
- The source action has to be an HTTP Request or Custom Action specifically; built-in integration actions can't currently serve as a chaining source
- The parent action has to be tested at least once inside the playbook editor, a real, live API call, not a simulation, before its response fields become available as variables downstream
- If a response returns an array of items, Zluri can't index into individual entries; it concatenates the chosen attribute across the whole array into a single comma-separated string
The Credential Models Behind Custom Automation
The overview notes that Custom Actions reuse an app's OAuth credentials and that HTTP Requests take manual credentials. The full model has a distinction worth understanding before building either.
Custom Actions come in two types with different credential behavior. A Custom Application Action, tied to one specific app, reuses that app's existing integration credentials by default. A Custom Zluri Action, usable across every application and playbook, has no app to borrow credentials from, so authentication always has to be supplied directly in the request configuration.
Building either walks through three sections: Action Details (name and description), Input Fields (each with a name, an auto-generated dynamic ID, a description, and a required flag), and Request Configuration (HTTP method, URL, headers, query parameters).
HTTP Requests split on the callback. A request without a callback fires one-way: telling an external system to do something, with no confirmation flowing back. A request with a callback supports the reverse: the external system reports completion status back to Zluri via a generated callback URL, requiring the response body to include a status field and an API key, moving the action from pending to completed once that callback succeeds.
That distinction decides whether an external step can gate the rest of a playbook or merely runs alongside it.
The Task Layer: When Nothing Automated Will Do the Job
Any action, from any category, can be converted to a Manual Task, tracked centrally through the Task Dashboard rather than left to an email someone might forget. This layer is what keeps the non-automatable path exactly as auditable as the automated one, and its anatomy is worth knowing in full.
Tasks can be assigned to an Individual, a Zluri Role, or a Group. Assigning to a group specifically means any member can pick it up, so the task doesn't stall because one particular person happens to be unavailable that day. Notification goes out by email, Slack, or as a created Jira ticket.
The dashboard itself supports status tracking (Pending, Completed, Canceled), bulk actions, and a permanent Task IDthat survives reassignment and is never recycled after deletion. That permanence exists specifically so the audit trail stays trustworthy no matter how many times a task gets picked up by someone new.
An Employee View versus Admin View toggle controls what's visible. Employees see their own and group-assigned tasks and can mark them complete or add comments; admins see every task organization-wide and can act on any of them.
One thing worth being deliberate about: anyone holding a direct task link can view and comment on it regardless of their own access permissions.
Why It All Has to Be One System
The reason none of this works as a collection of separate tools is that access management isn't actually three separate problems. Granting, updating, and revoking are one continuous problem viewed from three different moments in the same person's tenure.
A workflow builder that only handles onboarding well, a separate automation engine added later for offboarding, and a completely different mechanism for role changes would mean relearning three different systems, and losing the audit continuity that comes from tracking one identity's access history in one place.
Zluri's Access Management module is built so that the same actions, conditions, playbooks, manual task fallback, and audit trail apply whether the moment in question is someone's first day, their fifth promotion, or their last.
Frequently Asked Questions
Can the same application be added to a workflow more than once?
Yes, with a different configuration each time, and real sequences depend on it: one Slack block adding the person to #general, a second adding them to the team channel, both in the same workflow. The thing to watch instead is app variants, where the same search returns a full integration and a manual-task-only web variant with genuinely different capabilities.
What happens when a condition fails for a specific user mid-workflow?
It depends on the level. An app-block condition failing skips that entire application and the workflow moves on; an action-level condition failing skips only that one action while the rest of the block continues. That difference determines whether a partially matching user skips whole apps or receives apps with a subset of actions.
Can one action's output be used by a later action in the same playbook?
Yes, through output chaining, with three constraints: the source has to be an HTTP Request or Custom Action (not a built-in integration action), the source has to be live-tested once in the playbook editor before its response fields become available, and array responses get concatenated into a comma-separated string rather than being indexable entry by entry.
How does Zluri handle an application with no API access at all?
Any action for that application gets converted to a Manual Task, assigned to an individual, a role, or a group, tracked through the Task Dashboard with the same audit rigor (a permanent Task ID, full status history) as an automated step, rather than being handled as an informal side process outside the system.
.svg)
