Provisioning & Deprovisioning

Once access requests are approved, Zluri automates provisioning or generates manual tasks when automation is unavailable. Admins configure these outcomes using playbooks tied to automation rules.

Assigning Provisioning Playbooks

When a request is approved, Zluri can automatically provision access by running a linked Provisioning Playbook. This removes the need for manual IT intervention and speeds up access delivery.

Use cases:

• Apps that support provisioning via API, SCIM, or native connectors
• Frequent requests for standard roles or licenses
• Scenarios where minimizing turnaround time is critical

Setup steps:

1. Go to Admin View → Applications → [Select App] → Automation → Provisioning
2. Create or select a published playbook under the Provisioning Playbooks tab
3. Open Automation Rules → Access Requests → [Select Rule]
4. Under Provisioning Actions, select the playbook from the dropdown

Zluri will automatically execute the selected provisioning steps after request approval—whether the rule is auto-approve or routed through approvers.

Handling Expiry and Deprovisioning

When access is granted for a limited duration, Zluri can automatically revoke it by triggering a linked Deprovisioning Playbook. This is useful for enforcing temporary access policies.

Use cases:

• Interns, vendors, or contractors with time-bound access.
• High-risk apps requiring periodic revalidation.
• Temporary licenses with expiration dates.

Setup steps:

1. Go to Admin View → Applications → [Select App] → Automation → Deprovisioning
2. Create or select a published playbook under the Deprovisioning Playbooks tab
3. Link the playbook to an automation rule via Access Requests → Automation Rules → [Select Rule]
4. Under Deprovisioning Actions, select the playbook and configure trigger logic (e.g., based on access duration)

Zluri will run the selected deprovisioning actions automatically once the access period ends or conditions match.

This ensures that no user retains unnecessary access beyond their allowed time window, reducing risk and maintaining least privilege enforcement.

Fallback to Global Actions

When a request cannot be fulfilled through an automated playbook—due to missing connectors, unsupported applications, or unassigned logic—Zluri falls back to global actions. These actions ensure that approved requests are still completed through alternate methods.

Fallback actions can include:

• Manual Tasks – Created when no automated provisioning path is defined. These appear in Admin View → Tasks and include requester details, application, role, justification, and due date. Task owners must manually complete the action and mark the task as Completed.
• One-Time Notifications – Sent to stakeholders (e.g., app owners or approvers) to inform them of a request that requires manual follow-up or off-platform action.
• HTTP Requests – Used to push approved request data to third-party systems (e.g., internal bots, no-code tools, or external approval chains) via webhook.
• ITSM Ticket Creation – Automatically generate service desk tickets (e.g., in Jira) for tracking access provisioning through external workflows.

These global actions ensure that even without automation, Zluri can drive fulfillment and visibility across the request lifecycle.