Workflows

A workflow in Zluri is a sequence of automated steps used to onboard (provision) or offboard (deprovision) access for users.

Accessing Workflows

• Access to Zluri's Identity Governance & Administration (IGA) platform
• Administrator permissions for Workflows
• If issues occur with Workflows options, contact IT administrator or Customer Success Manager

Step 1: Navigation Steps

1. Log in to Zluri
   • Navigate to instance URL (For example, https://app.zluri.com/)
   • Most organizations use SSO-enabled login
   • If issues occur, try updating to the latest Chrome browser or contact the IT support team
2. Switch to IGA
   • Select the nine dot menu icon (top-left corner)
   • Select Identity Governance & Administration (IGA)
3. Open Workflows
   • In the left navigation panel, select Workflows
4. Select Module
   • Choose Onboarding for provisioning workflow
   • Choose Offboarding for deprovisioning workflow
5. Overview tab is the Default landing page
   • Start a new workflow from any of the two locations within the Onboarding/Offboarding module: Overview and Draft tab.
   • Select + New Workflow option

From the Overview Tab [Default]

From the Drafts Tab

The Drafts tab shows all saved draft workflows, making it convenient to start new workflows while managing existing ones.

1. Navigate to Workflows → Onboarding → Drafts
2. Select + New Workflow option

Note: Both options open the same workflow builder—they're placed in two locations for convenience.

Next Steps

After selecting + New Workflow, the user selection screen appears; select one or more users to onboard.

Learn user selection →

Step 2: SELECTING USERS FOR WORKFLOWS

After selecting + New Workflow, select one or more users to onboard or offboard. User selection is required before configuring applications and actions.

User Selection Screen

The screen displays all users in the organization for provisioning or deprovisioning, showing:

• Full name and email address

Selecting Users

Make Selection

Single user:

1. Select the checkbox next to the user's name
2. Select Continue

Example: Onboarding – Aaron Eckerly

Multiple users:

1. Select checkboxes next to multiple users
2. Select Continue

After Selection

Auto-Generated Workflow Name

• Single user: "Onboarding [First Name] [Last Name]"
• Multiple users: "Onboarding [Count] Users"

Change this later in the Settings tab.

Options Gets Enabled

Recommended applications and actions based on selected users' role, department, and location.

User attributes available for action parameters, variables, and conditions:

• Email, name, department, manager
• Variables like {{user.email}}, {{user.first_name}}
• Condition attributes like User Role, Department, Location, Status

Managing Users in Workflow Builder

After selecting Continue, selected users appear in the user menu at the top of the canvas.

Add more users: Select + Add More → Select additional users → Continue

Remove users: Select the X icon next to a user's name

Note: At least one user must remain selected.

Next Steps

After selecting users, the workflow builder opens, where the next step is to add applications.

Step 3: ADDING APPLICATIONS TO WORKFLOWS

Application Management

Before adding applications, understand Zluri categorizes applications based on authorization status.

Application Authorization Statuses

There are four primary authorization statuses for applications on the Zluri IGA platform:

1. Managed Apps (Green Tick Icon)

Applications discovered and managed within the organization. These are further classified into:

• Centrally Managed Apps All applications discovered and managed by an IT admin. These have full administrative oversight and control.
• Team Managed Managed by specific teams within the organization. Example: The Engineering team manages the GitHub application.
• Individually Managed Managed by individual users rather than centrally controlled by IT.

2. Restricted Apps

Applications restricted within the organization, typically due to:

• Security risks
• Malicious behavior
• Policy violations
• Compliance concerns

These applications cannot be provisioned through workflows.

3. Needs Review

Applications are currently under review by the IT administrator. Access decisions are pending administrative approval.

4. Unmanaged

Applications not managed by the IT admin within the organization. Using these apps makes individuals solely responsible for all possible risks they may pose.

Use caution: Provisioning unmanaged apps may introduce security or compliance risks.

Adding Applications to Workflows

After selecting users for onboarding, the next step is adding applications to the workflow. Select the + icon on the workflow canvas to begin.

The All Apps section expands to show three methods for browsing and adding applications: Search field, Recommended apps list, and Zluri Actions.

Three Ways to Add Applications

1. Search Field

Type the application name to find and add it to the workflow.

Searching for and selecting an application (For example, Slack) displays several details:

Application Details:

• Category - For example, Collaboration and Productivity
• Application Status - Active or Inactive
• Users Count - Number of users in the organization using this app (For example, 3311)
• Authorization Status - Team Managed or IT Managed

---

Integration Instance: If the app is integrated with Zluri, select from multiple instances (For example, Slack_0, Slack_1). Choose the instance best applies to the use case. Change instances by selecting on the currently selected instance name.

---

Available Actions:

Each application displays counts for available actions:

• Onboarding actions - Tasks for provisioning access
• Offboarding actions - Tasks for deprovisioning access

Example: Slack shows "10 Onboarding Actions" and "7 Offboarding Actions"

---

Multiple Integration Options:

Some applications return multiple options with different integration types.

Example: Searching "Okta" returns:

• Okta - Integration available (blue label)
• OktaWebOauth - No label (no direct integration)

These are distinct applications with different integration capabilities. Choose based on the integration setup.

2. Recommended Apps

Pre-suggested applications based on selected users, shown with app initials (For example, Z for Zendesk, HH for Hibob HRIS). Select the name of the app to add it to the workflow without searching.

Recommendations update based on user attributes like role, department, and location.

3. Zluri Actions

Understanding Integration Status

During application addition, Zluri indicates integration availability. This affects action automation capabilities.

Integration Available (Blue Label)

Applications with this label support automated provisioning and deprovisioning:

• Shows count of available automated actions
• Supports out-of-the-box integrations
• Can execute actions without manual intervention

Example: GitHub displays "Integration available" with 8 onboarding actions and 5 offboarding actions

No Integration (No Label)

Applications without this label have limited automation:

• Only manual tasks can be configured
• No automated actions available
• Requires human intervention to complete tasks

Example: GitHub Copilot shows no label and no action counts. The admin can only set up manual tasks for this application.

GitHub Integration Example

Understanding the difference between integration types:

GitHub (Integration Available)

• Label: "Integration available" (blue)
• Onboarding actions: 8 automated actions
• Offboarding actions: 5 automated actions
• Capabilities: Full automation support for adding users, assigning roles, managing repositories

GitHub Copilot (No Integration)

• Label: None
• Actions: Manual tasks only
• Capabilities: Limited to human-executed tasks; no automated provisioning

During GitHub searches, both options appear. Choose based on provisioning requirements.

Managing Applications in Workflows

Remove an Application

Use the three dot menu on an app block → Remove Application to delete the entire app block from the workflow.

Add Multiple Applications

The user can add multiple applications to a single workflow. Use the ‘+’ icon located at the following placements:

• Before the first app block
• Between app blocks
• After the last app block

There is no limit on the number of applications to be included in a workflow.

Reorder Applications

Applications execute in the order they appear in the workflow canvas. To change execution order, remove and re-add applications in the preferred sequence.

Next Steps

Once applications are added to the workflow, the next step is configuring actions for each application.

Step 4: CONFIGURING ACTIONS

Configuring Actions

Actions define the specific tasks each application performs during onboarding. For example, adding a user to Slack, assigning a GitHub license, or creating a Jira account.

This guide covers action groups, the process to add actions, configure their parameters, and manage them after configuration.

Action Groups and Classifications

Actions in Zluri are organized into groups based on their purpose. Understanding these groups helps select the right actions for the workflow.

Choose Action Menu

A Choose Action menu is a drop-down displaying actions grouped by type, such as Add, Update, Manual, Zluri Action, Delete, Custom Actions, and Others.

Example: Add Group

An Admin selecting an action from the 'Add' group in the Slack app block will see actions performing operations related to adding users to the application.

The Admin then chooses an action named ‘Add a New User To A Workspace’. Upon configuration, this action will add a new user to the Slack workspace. Similarly, other actions can be added to an app block.

Example: Delete Group

An Admin selecting an action from the 'Delete' group in the Slack app sees actions related to removing users from the workflow, such as "Deactivate User," which will deactivate a user from the Slack workspace.

Action Groups Available

Example: If John is a new joiner needing admin access to Slack, the playbook may include: An onboarding action adding him to a Slack channel. A Zluri action marking him as a Slack admin in the Zluri system. | | Others | Typically includes "Create a Manual Task." In the Zluri Action app block, it lists: Create a Manual Task, Make an HTTP Request, Make an HTTP Request with Callback. Manual Task: Creates a task in the Tasks section for manual completion. Used for unavailable automated actions or preferred manual execution.

Learn more about Manual Tasks | | Custom Actions | Displays actions custom-built by Zluri admins to support automations not available through Zluri's out-of-the-box capabilities.

Learn more about Custom Actions | | SSO (Single Sign-On) Actions | Automations run through SSO systems (Okta, Azure AD, Google Workspace) acting as a centralized identity layer. Includes adding users to groups or applications on SSOs to handle authentication automatically or support provisioning through SSOs. |

---

Add an Action

At the bottom of each app block, select + Add an action to open the action selection menu.

Choose Action Menu

A Choose Action menu appears displaying actions grouped by type. Available groups include:

• Add - Actions to provision or add resources
• Update - Actions to modify existing configurations
• Manual - Tasks requiring human completion
• Zluri Action - Platform-specific actions
• Delete - Actions to remove or deprovision resources
• Custom Actions - User-created custom integrations
• Others - Miscellaneous actions

The list of available actions depends on the selected application.

Example: Slack Application Actions

Upon selecting Choose Action for the Slack app, actions are grouped as follows:

Add group - Actions to perform operations related to adding users:

• Add a New User to Workspace
• Create a Channel
• Invite User to Slack Channel
• Add User to Group
• Update Title
• Add Display Name
• Set a Reminder for the User

Update group - Actions for modifying existing configurations:

• Mark Reminders as Complete
• Update User Status
• Send a Message to the Channel

Available action groups vary by application. Slack shows Add and Update groups for onboarding; other applications may show different groupings based on their capabilities.

Configure Action Parameters

After selecting an action (For example, "Add a new user to workspace" for Slack), a configuration window opens with multiple options.

Convert to Manual Task

Convert automated actions to manual tasks if manual execution is preferred for security or process reasons.

Use cases:

• Security requirements mandate manual approval
• Actions require special handling
• Automation not suitable for sensitive operations

Learn more about Manual Tasks

Advanced Features

Apply Condition

Set rules determining this specific action's execution based on user attributes (role, department, status, etc.).

Example: Only invite user to #engineering-team channel if department = Engineering

Conditions use user attributes like:

• Role
• Department
• Location
• Designation
• Status
• Account type

Learn more about setting conditions

Require Approvers

Assign approvers for sensitive actions. Adds an extra layer of control ensuring high-impact actions are reviewed and explicitly approved before execution.

Method to follow:

1. Specify one or more approvers
2. During workflow runs, approvers receive notifications
3. Action executes only after approval
4. If approval is denied, action is skipped

Use cases:

• Granting admin access
• Assigning expensive licenses
• Providing access to sensitive data

Add Delay

Schedule action execution timing after playbook trigger. Configure delay in:

• Weeks
• Days
• Hours
• Minutes

Use cases:

• Send welcome email 1 day after account creation
• Assign advanced tools after 1 week probation
• Trigger training modules after 3 days

Delays help sequence actions and ensure staged provisioning.

View Prerequisites

Displays prerequisites necessary for successful action execution.

Common prerequisites:

• Plan tier requirements - Certain actions only work on higher-tier plans (Basic/Business vs. Enterprise)
• License requirements - Specific licenses needed for the action
• Integration requirements - Required connections or permissions

Different actions have different prerequisites, clearly indicated so admins can verify requirements while setting up the workflow.

Update in Zluri

(Appears only for Add and Delete type actions)

This checkbox automatically adds or removes the user from the application in Zluri's system upon completion of the action.

Benefits:

• Keeps Zluri's records synchronized with actual application access
• Ensures accurate license tracking
• Maintains up-to-date user directories

Enable during:

• Add actions: Automatically registers user as having access
• Delete actions: Automatically removes user from Zluri records

Save Task / Cancel

Save Task Saves the action configuration. Required for changes to take effect in all subsequent runs of the workflow or playbook.

Cancel Discards all configurations:

• Adding a new action: Removes all settings and requires setup from scratch
• Editing an action: Reverts to previous configuration

Add Multiple Actions

Select + Add an action at the bottom of the app block to add another action to the same application.

User or admin can add:

• Multiple instances of the same action with different parameters
• Different actions from various action groups
• Mix of automated and manual actions

Example: For Slack, add:

1. Add a New User to Workspace
2. Invite User to #general channel
3. Invite User to #engineering channel
4. Add User to Engineering Group

Action Counts Breakdown

Adding an application with integration available displays detailed action counts.

Example: Slack Application

10 Onboarding Actions:

Add actions (7 total):

• Add a New User to Workspace
• Create a Channel
• Invite User to Slack Channel
• Add User to Group
• Update Title
• Add Display Name
• Set a Reminder for the User

Update actions (3 total):

• Mark Reminders as Complete
• Update User Status
• Send a Message to the Channel

7 Offboarding Actions:

Delete actions (7 total):

• Remove User from all Groups
• Delete Reminders
• Remove User from Slack Group(s)
• Remove User from all Channels
• Deactivate Users
• Sign Out User (Manual task)
• Remove User from Channel(s)

Manage Configured Actions

After selecting Save Task, the configuration window updates to show additional controls and information.

Integration Instance Selector

Displays the currently selected integration instance (For example, "BambooHR-zero-touch").

If multiple instances of an application are integrated with Zluri, select the arrow next to the instance name to select a different instance for this workflow.

All integration instance names appear in the dropdown (For example, BambooHR-zero-touch, BambooHR-prod, BambooHR-staging).

View Prerequisites

Displays prerequisites again for the requirement review. Shows the same information as during initial configuration.

Edit Action / Edit Task

Edit Action - Appears for automated actions. Reopens the configuration window to modify parameters.

Edit Task - Appears for manual tasks. Similar functionality with manual task-specific fields.

The features and options in Edit Task are nearly identical to Edit Action.

Delete

Removes this action from the workflow completely. The action is permanently deleted and cannot be recovered.

Blue Ribbon Note

This blue ribbon note appears during incomplete or missing parameter configurations, indicating required fields needing completion.

Parameters Configured

Select the arrow to expand and view all configured parameter details for this action.

Shows the complete configuration, including:

• Parameter names and values
• Applied conditions
• Assigned approvers
• Configured delays
• Integration instance

Execution Controls

Three icons appear next to "View Prerequisites" to control the execution of actions.

1. Wait Until Completion (Yellow Clock Icon)

Controls whether the next action waits for this one to complete.

Functionality: The next action executes only after this action reaches a terminal state (completed or failed, including approval not granted).

Note: For automated actions, this is always ON and cannot be turned OFF. Automated actions must execute sequentially to ensure workflow completion and data integrity.

2. Break on Error (Toggle Switch)

Controls workflow behavior during action failure.

OFF (default - grey switch)

• Workflow continues executing remaining actions even if this action fails
• Subsequent actions attempt to run normally
• Useful for non-critical actions

ON (blue switch)

• Workflow stops immediately during action failure
• No further actions are performed
• Prevents cascading errors

To enable: Select the three-dot menu next to the icon and toggle the switch.

Use cases for Break on Error ON:

• Critical provisioning steps (For example, creating user account)
• Actions on which other steps depend
• Security-sensitive operations

Use cases for Break on Error OFF:

• Optional actions (For example, adding to non-critical groups)
• Actions failing without affecting workflow success
• Nice-to-have provisioning steps

3. Three Dots Menu

Contains the same controls (Wait Until Completion and Break on Error) with ON/OFF sliders to activate or deactivate for specific actions.

Provides quick access to execution control settings without opening full configuration window.

---

Next Steps

After configuring actions, learn to control execution timing using conditions.

Step 5: SETTING CONDITIONS

Setting Conditions

Conditions control application and action execution based on user attributes. Zluri provides two types of conditions for granular access control:

• Apply Condition - For a single action within an application block
• Add Condition - For the entire application block in a workflow

Where to Find Condition Options

To address granular access control, the Zluri access management module provides configurable conditions. There are two types of condition features available in Zluri's IGA platform:

A. Apply Condition (Action level)

B. Add Condition (App level)

Let's discuss both types of conditions.

---

A. Apply Condition

Apply Condition (Action level) - Conditions applied to a single action within an app block.

Key characteristics:

1. Applied at the individual action level (placed below each action added)
2. Controls whether a specific action executes (For example, adding a user to a particular GitHub repository only if the role is 'Software Engineer')

Admins can create rules by selecting attributes from the 'Search Attributes' field to define conditions.

(Note: These are different from automation rules.)

We'll use the Slack app as an example to explain the Apply Condition feature and its functionality.

Step 1: Access Apply Condition

Select Apply Condition in the action configuration window where action is selected (For example, "Add a new user to workspace" for Slack).

Step 2: Select the attributes to create the condition

Search attributes field has a list of attributes options to select from, which includes, but is not limited to, the following attribute types and options:

• User Account Type → Select account type from the list.
• User Created at → Select date.
• User's current department → Search entity name from the list.
• User's current designation → Select string type.
• User reporting manager → Search from entity names.
• User Role → Select role name from the list.
• User Status → Select status
• App owner → Search for the entity name, etc.

Step 3: Using Operators ‘AND’ and ‘OR’ for Conditions

After selecting attributes and configuring parameters, use the operators 'AND' and 'OR'. Admin or user may choose 'AND' or 'OR' separately or in combination, depending on the requirements.

1. AND Operator The AND operator is used for rules requiring multiple conditions to be met simultaneously.

   Example:

   [Attribute = User Role; Operator = equals; Value = Admin]
   AND
   [Attribute = User Status; Operator = not equals; Value = Suspended]
   

   

   In this case, the rule will trigger only if the user's role is Admin and their status is not Suspended. If either of these conditions is not true (For example, if the user is suspended or not an admin), the rule will not trigger.

2. OR Operator Use the OR operator for rules requiring any one of multiple conditions to be met for execution.

   Example:

   [Attribute = User Role; Operator = equals; Value = Marketing Manager]
   OR
   [Attribute = User Role; Operator = equals; Value = Sales Manager]
   

   This rule will trigger if the user is either a Marketing Manager or Sales Manager, and will not require both conditions to be true.

Step 4: Edit Condition Window

After saving conditions, they appear as "X conditions applied" below the action name. These conditions apply only to the specific action (For example, "Add to Group") within the app block.

To edit conditions:

1. Select the Edit Action option
2. Select the Conditions blue link
3. The Edit Conditions window opens

Available actions:

• Add more configurations - Configure additional rules

• Remove individual conditions - Use the X option next to each condition

  

• Remove all conditions - Select the Remove Conditions option

  

• Save changes - Select Save Conditions to apply all updates for this specific action

• Cancel changes - Select Cancel to retain the current configuration without changes

  

Complex Conditions Example

Admin or user can create sophisticated rules using both AND and OR operators. For example, seven conditions can be applied using AND and OR combinations for different attributes.

Remember: All configured conditions are applicable only to one specific action (For example, "Add a new User to workspace") and NOT to the entire Slack application in the workflow.

Refer to the image below, which explains seven conditions are applied using AND and OR combinations for different attributes.

The screenshot below shows the seven conditions configured in the previous section.

Below is a GIF showing the configuration for all seven conditions, using both ‘AND’ and ‘OR’ logical operators applied to the Action.

B. Add Condition [Conditions for complete Application]

Add Condition (App level) - Conditions applied to the complete app block.

Key characteristics:

1. Applied at the application block level (option located at the top-right of the app block)
2. Controls whether the entire app block runs (For example, only run the GitHub block if Department = Engineering)

Below are the steps for adding a condition to an application (using Slack as an example).

Step 1: Access Add Condition

Select the three dot menu at the top-right of the application block, then select Add Conditions.

The three dot menu has two options:

• Add Conditions - Sets conditions for the entire application
• Remove Application - Removes the complete application block from the workflow

Step 2: Search Attributes

Search Attributes offers various options to select from, similar to the 'Apply Condition' case.

Step 3: Using Operators 'AND' and 'OR' for Conditions

After searching and selecting attributes, use the operators 'AND' and 'OR'. Choose 'AND' or 'OR' separately or in combination, depending on the requirements. This works similarly to the logical operators discussed in the 'Apply Condition' section.

Step 4: Edit Condition Window

After saving, conditions appear as "X conditions applied" at the top of the app block. These conditions apply to the entire application block (For example, the Slack application), and not just to a single action within the app block.

The configured parameters appear upon selecting the 'X conditions applied' text (X = the number of conditions applied). This count changes based on adding or removing conditions for the application block.

To edit conditions:

1. Select the Edit Conditions option
2. The Edit Conditions window opens

Available actions:

• Add more configurations - Configure additional rules or use the X cross option next to each condition to remove a specific condition.

  

• Remove all conditions - Select the Remove Conditions option to delete all conditions applied to the application

  

• Save changes - Select Save Conditions to save all updates for the app block conditions

• Cancel changes - Select Cancel to retain the current configuration without changes

  

Understanding Condition Placement: Apply Condition vs. Add Condition

Conditions appear in two distinct locations within the workflow, making it easy to see where they're applied.

App-Level Conditions (via Add Condition)

The conditions count is displayed at the top of the app block. This is configured via the Add Condition option.

Example: "3 conditions applied" - Selecting this blue text link shows the configurations applied to the entire Slack application block.

Action-Level Conditions (via Apply Condition)

The conditions count appears beneath the specific action. This type of condition is configured via the Apply Condition option.

Example: "7 conditions applied" - Selecting this blue text link shows the configurations applied to one action named "Add new user to workspace" within the Slack application block.

Note: Admin or user can add conditions to multiple actions within the same app block. For example, admin might add one condition to the "Create a Channel" action - selecting "1 condition applied" shows the details for a specific action. Each action displays its own condition count independently. Follow the example shown below.

Condition Evaluation Logic

During App-Level Conditions Fail

• Entire app block is skipped
• No actions within the app execute
• Workflow continues to next app block

During App-Level Conditions Pass

• Workflow proceeds to evaluate actions
• Each action's conditions are checked
• Actions with passing conditions execute
• Actions with failing conditions are skipped

During Action-Level Conditions Fail

• Only the specific action is skipped
• Other actions in the same app block continue
• App block overall continues execution

Common Condition Scenarios

Scenario 1: Department-Based Access

App-level: Department = Engineering
Actions:
  - Add to GitHub (no additional conditions)
  - Add to Jira (no additional conditions)
  - Add to Slack #engineering (no additional conditions)

Scenario 2: Role-Based Permissions

App-level: None
Actions:
  - Create user account (no conditions)
  - Assign basic license (no conditions)
  - Assign admin license (Role = Admin OR Role = Manager)

Scenario 3: Location and Role Combined

App-level: Location = US OR Location = UK
Actions:
  - Add user (Status = Active)
  - Grant admin access (Role = Admin AND Status = Active)

Next Steps

Once the conditions are configured, learn to execute the workflow.

Step 6: RUNNING WORKFLOWS

Running Workflows

Once the workflow is configured with applications, actions, and conditions, it is ready for final execution. Zluri offers three options for running workflows, plus automatic draft saving.

1. Auto-Save as Draft

Workflows automatically save as drafts if they are not explicitly run or saved. This feature prevents work loss from technical issues or forgotten saves.

Functionality

If no execution actions are performed (Run, Save as Playbook, or Schedule for Later), the unfinished workflow remains listed under the Drafts tab for further editing.

Drafts are auto-saved if the admin or user:

• Navigate away from the workflow page
• Session times out
• Close browser
• The system detects inactivity

Resume Editing

Find the auto-saved draft in the Drafts tab. Select Edit to continue configuration.

Draft retention: Drafts remain available indefinitely until the admin or the user deletes them or converts them to playbooks.

2. Save as Playbook

Convert the workflow into a reusable template stored in the Playbooks tab.

Playbooks Use Cases

• Onboarding multiple users with the same role
• Standardizing provisioning across departments
• Creating templates for common scenarios
• Building library of reusable workflows

Steps to Save as Playbook

1. Select Save as Playbook in the top menu
2. Provide a playbook name
   • Use descriptive names (For example, "Engineering Onboarding", "Sales Manager Provisioning")
   • Include role, department, or scenario in the name
3. Select Save

The workflow is now available in the Playbooks tab for future use.

Benefits of Playbooks

• Consistency - Every user receives identical access
• Efficiency - No need to rebuild workflows from scratch
• Scalability - Run the same playbook for dozens of users
• Compliance - Standardized access reduces audit risks

Learn more about creating and managing playbooks

---

3. Run

Execute the workflow immediately or schedule for later execution.

Run Immediately

Select Run → Run Workflow Now for immediate execution.

Next steps:

1. Workflow validates all configurations
2. Actions execute in order for selected users
3. Real-time status updates appear in the interface
4. Execution completes with success or failure status

Results recorded in:

• Run Logs tab with complete execution details
• Timestamps for each action
• Success/failure status for each step
• Error messages for failed actions

Use cases:

• Emergency access provisioning
• Single user onboarding
• Testing new workflows
• Ad-hoc access requests

Schedule for Later

run schedule for later (online-video-cutter.com).mp4

Select Run → Schedule for Later to execute at a future date and time.

Configuration options:

1. Select Timezone Choose the appropriate timezone for execution. Important for distributed teams to ensure workflows run at the correct local time.

2. Specify Date Pick the future execution date using the calendar picker.

3. Choose Run Time Set the specific time (hours and minutes) for execution.

4. Confirm Scheduling Type "CONFIRM" in the confirmation field to prevent accidental scheduling.

After scheduling:

• Scheduled workflows appear in the Scheduled Runs tab
• View all upcoming scheduled executions
• Edit or cancel scheduled runs before execution
• Receive notifications for completed scheduled runs

Use cases:

• New employee start dates (provision access day before or morning of start date)
• Coordinated team onboarding
• After-hours provisioning to avoid business disruption
• Timezone-appropriate execution for global teams

---

Execution Validation

Before running, Zluri validates the workflow configuration:

Required Elements Checked

• Users selected - At least one user must be selected
• Applications added - At least one application with actions
• Actions configured - All actions must have complete parameters
• Prerequisites met - All action prerequisites must be satisfied
• No blue ribbon notes - All required parameters filled

Step 7: ADVANCED OPTIONS

Advanced Workflow Options

For specialized use cases, workflows support advanced features extending the automation capabilities beyond standard integrations.

1. Create Variables

Variables dynamically fetch user-specific data during workflow execution. Instead of hardcoding values like names, emails, or departments, use variables to insert information automatically.

Variables

Variables are placeholders for pulling data from user profiles or application records at runtime.

Example variable syntax:

• {{user.first_name}} - User's first name
• {{user.email}} - User's email address
• {{user.department}} - User's department
• {{user.manager}} - User's manager name

Variables Use Cases

Welcome emails:

Subject: Welcome {{user.first_name}} to {{user.department}}!
Body: Hi {{user.first_name}}, your manager {{user.manager}} is excited to have you join the team.

Application provisioning:

• Create user accounts with dynamic usernames
• Assign licenses based on user attributes
• Set permissions based on role or department

Notifications:

• Send customized alerts with user-specific details
• Include dynamic information in Slack messages
• Personalize email templates

Benefits

• Reusable workflows - Same workflow works for any user
• Automatic personalization - No manual data entry required
• Reduced errors - Eliminates copy-paste mistakes
• Scalability - Process hundreds of users with one playbook

Available Variables

Variables pull from:

• User profile data (name, email, role, department, location, manager)
• HRMS integrations (employee ID, hire date, employment type)
• Custom user attributes configured in Zluri
• Application-specific data

Learn more about creating variables and dynamic inputs with all available attributes →

---

2. Custom Actions and HTTP Requests

Build tailored integrations for applications without native Zluri support. Configure custom API calls and HTTP requests to extend automation capabilities.

Custom Actions

Custom actions allow to:

• Call external APIs
• Send HTTP requests (GET, POST, PUT, DELETE)
• Integrate with internal tools
• Connect to proprietary applications

Custom Actions Use Cases

Custom internal tools: The organization uses proprietary software not in Zluri's integration catalog.

Specialized integrations: Need to call specific API endpoints not covered by standard integrations.

Advanced workflows: Require custom logic or data transformation during provisioning.

Third-party services: Integrate with external services via webhook or API.

Learn more about custom actions and HTTP requests →

---

3. Manual Tasks

Convert automated actions to manual tasks when automation is unavailable or preferred manual execution is required.

Manual Tasks

Manual tasks are workflow steps requiring human intervention. Instead of automated execution, Zluri assigns tasks to designated people with instructions for completion.

Manual Tasks Use Cases

No integration available: Application doesn't have Zluri integration (For example, GitHub Copilot).

Security requirements: Organization policy mandates manual approval for certain actions.

Complex procedures: Task requires human judgment or multi-step verification.

Approval workflows: Need documented human confirmation before provisioning.

Learn more about manual tasks →

---