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.