Workflow is a feature by Zluri that enables IT administrators to automate their SaaS operations. Zluri currently offers two types of workflows.

1. Onboarding workflows - You can use Onboarding workflows to Add a user, Assign license to a User, Add user to different groups for different applications when a new user is added to your organization. You can do all this directly from Zluri.

2. Offboarding workflows - You can use Offboarding workflows to Remove a user, Remove license from a User, Remove user from different groups for different applications when a user is leaving your organization. You can do all this directly from Zluri.

The onboarding workflow contains 3 tabs. 

1. Draft: It lists the workflows which are not completely set up.

2. Templates: You can set up a workflow & save it as a template to run later.

3. Completed: This tab lists the completed workflows.

Creating & running an onboarding workflow:

Please follow the below steps to create & run an onboarding workflow.

Click ‘New workflow’ to create workflow.

Select the users to onboard.

Select the application for which you want to run the workflow & add the actions. 

So what are Recommended Applications and Recommended Actions?

While setting up a workflow for a user, Zluri provides you with a set of recommended applications for the user. This is typically done on the basis of commonly used apps by your organization. 

Each such application again comes with a set of recommended actions you should take for each app while onboarding. The recommended actions for each app are decided by Zluri based on the tag i.e. Onboarding/ Offboarding/Others on the workflow action.

The recommended apps for each user while onboarding are populated based on looking at the top apps used by other users in the organization with the same designation and department. This set of recommended applications can act as a checklist for you.

Once you completely set up the actions you can either save it as a template or run the workflow. 

You can save a workflow as a template. If all the actions are completely set up and the template is ready to be used, it is saved as a “Published” Playbook, which just means it is ready to be used. If all actions are not set up and there are still errors in the workflow, the template gets saved with an “Unpublished” Playbook tag, which means the playbook is not ready to be used yet. Move to the next section for more about Playbooks.

To run the workflow, Please click on the ‘Run’ button at the top right corner. It will prompt you to type ‘CONFIRM’ on the text box. Please type ‘CONFIRM’ & click ‘Run workflow.

NOTE: A workflow can only be run after all the actions in the workflow are completely set up.

You can use the Overview section to create a new workflow or use an existing playbook. The following categories are available in the Onboarding section of the Workflow module to provide information on current workflows and existing playbooks, user information and activity logs, etc:

This section provides the list of onboarding workflows currently in progress. You can click on the View All button to view the complete list of Workflows currently under process.

You can apply various filters on your workflow run logs screen to view specific workflows you want to track : 

You can also view the activity log by clicking on the app name or the View log button next to each app. This will take you to the activity log for the particular workflow execution, where you can view the run log and raw log of each playbook of the workflow. You will also find the necessary actions you should take as the next steps for failed actions. 

A Playbook is a Template of rules/actions performed by a workflow, i.e. add a user, give access to the user etc. The playbooks tab displays the list of all playbooks currently being saved by your organization in the Zluri Dashboard. Playbooks come with two tags : 

1. Published - All actions are set up, and the Playbook is ready to be used.

2. Setup Required - All actions are not set up, and the playbook can’t be used. 

In the playbook list, you can perform the following actions:

Summary of Playbook: You can view the summary of the playbook - All apps and actions in the Playbook by clicking on it; this can be useful if you just want to check if everything is ready and set up and ready to be used.

Edit playbook: You can use the edit playbook button for Playbooks with the “Setup Required” tag. These playbooks can only be edited and not be used just yet. Then, you can create or edit actions under each playbook.

Run a Playbook: You can use a Published playbook by clicking on the Run a Playbook button for the playbook and selecting users, and following the prompt to run the Playbook.

Delete Playbook: You can delete an existing playbook by clicking on the Three dots and afterwards by clicking on “Delete Playbook”.

This category lists the apps that have been recently edited and show all the relevant details, like user information. Click on the Edit option next to an app, and it will take you to the Edit section, where you can add or delete the particular draft of the playbook.

Clicking on the View all button on the top right will take you to the Drafts tab where you can also access individual draft edit menus.

The onboarding section has five tabs in total. They are: 

• Overview

• Drafts

• Playbooks

• Recent runs

• Automation rules

We have already accessed the first three from the Overview tab. Now let us have a look at the remaining 2.

This tab displays the list of recently run playbooks. You can filter the information available in the list by clicking on the Filter button and applying one or multiple filters:

You can also click on the View log button as previously demonstrated to view the playbook log details.

You can perform the following actions in the Log section:

• View the Error/Success message for each action

• Retry action for failed 

• Convert to manual task

• Retry all failed

• View the raw log to view the detailed action report.

• Export log

This section allows you to create rules for your playbook and view the existing set of automation rules and relevant information. To set a new rule, click on the New Rule button on the top right of the screen.

The onboarding rule creation screen opens.

You can set the following parameters for the rule:

1. Add trigger: Define a trigger that runs your automation. There are mainly three kinds of triggers:

• User Status Changes

• New User Added/Discovered In Zluri

• The user Is Marked For Onboarding

2. Add attributes: This enables you to selectively run the automation based on the conditions that can be set from the list below:

• Reporting Manager: This is usually the name of the employee’s reporting manager.

• User Designation: The name of the designation that applies to the user.

• Last Active: This usually is in numeric format and denotes the timestamp of the user's last activity.

• User Account Type: Usually, in text, this denotes whether the user account is an admin account or any other type.

• Critical Apps Used: The number of critical apps the user uses is an attribute here.

• Primary Source: The name of the app/apps used as the primary source for creating the condition.

• User Department: The name of the user department.

• Role: This is the name of the user role.

• Created At: a number denoting the timestamp to be used as a condition.

• Risk Level: A number denoting the risk level associated with the particular condition.

• Apps Used: The number of apps used to set the particular condition.

• User Status: a text denoting the current user status based on which the condition can be set.

3. Add a playbook: Choose to run an existing playbook for the new rule.

4. Add Delay: This is used to set a time delay after which the rule will be executed. Delays can be really helpful when working with multiple automation rules, as you might want to cascade automation rules. 

(For example, you may create an automation rule for providing access to general apps used across an organization when a New user is Onboarded, and this will run automatically immediately as soon as Zluri detects a new User marked for onboarding. 

For convenience, you can set the admin access time with a delay of 2 days after a New user is marked for onboarding. Then this automation rule can  give access to specific apps used by department users.)

5. Save rule: You can save the rule once all the previous conditions have been set.

From the list of rules available, you can perform the following actions:

1. Edit/Delete a rule by clicking on the 3-dot option next to each rule.

2. You can change the status of a rule and set it to active/inactive by clicking on the toggle below the status column.

You can manually drag each rule by the arrow next to the rule name to put it above/below a rule. This will help you set the Order of the rule.

The offboarding workflow also contains three tabs. 

1. Draft

2. Templates

3. Completed

You can follow the same process to create & run an offboarding workflow as we do for an onboarding workflow, i.e. click on New workflow and select users to set up. 

You will see that all apps are already populated with actions set up for a particular user; Zluri uses its discovery capability to discover all the apps that the user had used being part of your organization and sets up all actions to offboard a user from all these apps. 

You can use the Overview section to create a new workflow or use an existing playbook. The following categories are available in the Offboarding section of the Workflow module to provide information on current workflows and existing playbooks, user information and activity logs, etc:

This section provides the list of offboarding workflows currently in progress. You can click on the View all button to view the complete list of Workflows currently under process.

You can also view the activity log by clicking on the app name or the View log button next to each app. This will take you to the activity log for the particular app playbook where you can view the run log and raw log of each playbook of the workflow.

An offboarding Playbook is a template of rules/actions that are performed by a workflow i.e Remove a user, Remove access to a user etc. This tab displays the list of all playbooks currently being saved by your organization in the Zluri Dashboard. There are two types of offboarding playbooks onboarding playbooks : 

1. Published - Play Books which are completely set up i.e. all actions are set up, and the playbook is ready to be used. 

2. Setup Required - Playbooks which are not completely set up, and the playbook is not ready to be used yet.

In the playbook list, you can perform the following actions:

Summary of Playbook: You can view the summary of a playbook i.e. all the apps and the actions which are included in the playbook by clicking on a Playbook. This can be really useful and good practice to have a last look at a playbook before using it to check if all your requirements are covered in the playbook.

Run a playbook: You can use an existing playbook to offboard users from your SaaS apps directly from Zluri. Simply click on the Run Playbook button. Note that you can only run Published Playbooks.

Edit playbook: You can use the Edit playbook option for Setup Required Playbooks or use the Edit playbook option after clicking a Published playbook to move to edit mode. Here you can create or edit actions under each playbook.

Delete Playbook: You can delete an existing playbook from the edit playbook menu by clicking on the three dots on the top right corner of the playbook.

Recently Edited

This category lists the apps that have been recently edited and shows all the relevant details like user information. Click on the Edit option next to an app and it will take you to the Edit section where you can add or delete the particular draft of the playbook.

Clicking on the View all button on the top right will take you to the Drafts tab where you can also access individual draft edit menus.

The onboarding section has five tabs in total. They are: 

• Overview

• Drafts

• Playbooks

• Recent runs

• Automation rules

We have already accessed the first three from the Overview tab. Now let us have a look at the remaining 2.

This tab displays the list of recently run playbooks. You can filter the information available in the list by clicking on the Filter button and applying one or multiple filters:

You can also click on the View log button as previously demonstrated to view the playbook log details.

You can perform the following actions in the Log section:

• View the Error/Success message for each action

• Retry action for failed 

• Convert to manual task

• Retry all failed

• View the raw log to view the detailed action report.

• Export log

This section allows you to create rules for your playbook as well as view the existing set of automation rules and relevant information. To set a new rule, just click on the New Rule button on the top right of the screen.

The onboarding rule creation screen opens.

You canset the following parameters for the rule:

1. Add trigger: Define a trigger that runs your automation. There are mainly three kinds of triggers:

• User Status Changes

• New User Added/Discovered In Zluri

• The user Is Marked For Onboarding

2. Add attributes: This enables you to selectively run the automation based on the conditions that can be set from the list below:

• Reporting Manager

• User Designation

• Last Active

• User Account Type

• Critical Apps Used

• Primary Source

• User Department

• Role

• Created At

• Risk Level

• Apps Used

• Usage

• User Status

3. Add a playbook: Choose to run an existing playbook every time the rule is triggered.

4. Add Delay: This is used to set a time delay after which the rule will be executed.

5. Save rule: You can save the rule once all the previous conditions have been set.

From the list of rules available, you can perform the following actions:

1. Edit/Delete a rule by clicking on the 3-dot option next to each rule.

2. You can change the status of a rule and set it to active/inactive by clicking on the toggle below the status column.

        You can manually drag each rule by the arrow located next to the rule name to put it above/below a             rule. This will help you set the Order of the rule.

App requisition automation rules

Admins will be able to set up multiple automation rules to apply for different license approval processes followed within the organization. 

These rules can be set up in a way where different request conditions will trigger a different approval workflow

For instance, if an organization follows a different workflow for each department, different rules can be set up for each department such that it goes through a different approval process. Or if there’s a different approval process for apps that are already managed by the organization and apps that need to be newly procured, a different approval process can be set up

Automation rules allows you to do this using two important components - ability to set up conditions for each rule, and configuring different approvers for each rule

Each rule can have two sets of conditions - check whether the application is already used by the org or not, and more specific criteria such as the requester’s department, designation, reporting manager, or the specific application requested. This helps create very specific approval workflows that apply to each request that’s raised

Each rule can also have its own set of approvers that will need to take an approval action for every request that fits the conditions of that rule. For example - a request raised by a member of the sales team can have the most relevant members approve that request, say the employee’s reporting manager, the head of sales, and then the IT admin 

In the overview section of any particular app, Zluri provides the employee to request a particular license or an app. This request by the employee involves specific steps, which are explained further in the doc.

1. Step 1: The employee must fill out the application and license tier names. The cost/Licence/term is pre-typed based on the data of 225k applications of Zluri’s library. The employee can change the cost as per the current needs. 

2. Step 2: Zluri prompts similar applications with optimal license costs when the user clicks on the continue button. The user can choose to go for the recommended apps or ignore the recommendations and continue with the request process. 

3. Step 3: A page containing the detailed version of the request is generated where the employee has to describe the need for the request. The employee must also upload the necessary documents to justify his/her needs. 

The employee dashboard has a provision to view all the requests, including license requests and app requests. 

This page contains all the basic details. This view provision also displays the status of the request helping the employees in keeping track of all the requests. The employee can also add new requests from this page which is proof of a seamless UI experience. 

The visualizations help them better comprehend their application usage.  

After the requesting process, Zluri offers a 3-level hierarchy of approval. Application managers, Reporting managers, and IT admins. 

In this approval process, the power to override the approval or rejection decision depends on the authority level. The higher authority can override the decision taken by the lower admins or the managers.  

The admins also add comments explaining why the request was rejected. 

In an ideal approval situation, only the assigned approval authority approves the request. However, Admins have the authority to approve a request on behalf of an approver at each stage of the approval process.

Whenever the approval status is pending a particular approval, the admin can approve, reject or notify the approver.

Approve on behalf of an approver -

1. If approver one is pending, and admin approves

   1. Admin gets added as a new approver after approver 1, and the status will be “Approved on behalf of approver 1.”

   2. Approval update and action required notifications for approver 2, admins, and requestee will get triggered accordingly.

2. The same logic holds for the rest of the approvers.

1. If approver one is pending, and admin rejects it -

   1. Admin gets added as a new approver, and status will be “Rejected on behalf of approver 1.”

   2. Rejection notifications for other approvers, requestee, and admins will be triggered.

   3. The request's status changes to “rejected” on the “All Requests” page.

2. Any stage of rejection will reject the complete request process.

Admins have the right to override the rejected request from any of the rejection stages. Admin will see the option to override rejection, and once they reject, “approval update” and “action required” notifications for the next approver, admins, and requestee will be sent.

In the process, there is also an option to add new approvers among the default approvers list. The names can be searched within the organization, and the selected approver can be dragged and placed anywhere among the list of approvers.

Once done, the notifications are sent to all the stakeholders assigned.

We have an option to add approvers based on roles as well. It can be configured in the “automation rules” section of the workflows. In the approver summary, “roles or approver” can be added by selecting the required role/approver from the dropdown.

Notes should be added that admins will be notified to add approvers in case of role unavailability. Saving it triggers the rule which will be reflected on the “request summary” page.

Onboarding actions  -

Similarly to adding roles and approvers, different approval actions can be added too. In the automation rules section of the workflows, approval action can be added. As an action, the option to “run playbook” can be selected. The configuration can then be done based on what playbook to run, what should be the delay and the mail selection in case of failure.

Offboarding actions  -

The offboarding playbook can be run similarly. The “Run offboarding playbook” option is selected in the “Add action” menu bar, to which the delay and reminder can be added accordingly. Once done, the rule can be saved and triggered automatically.

The employee must keep track of the changes happening in this process. Hence Zluri introduces a change catalogue. 

The employee can see all the updates on the request made. 

The approval and rejection from the higher admins, the change in the duration of the basic detail of the license, and the comments added by the admins are all displayed so that the employee is always kept updated on the request's status. 

Once an employee requests an application or a license, the request is then sent to the approver for their approval. The requests are all in one place for approval.