Zluri's employee dashboard is a single place for your employees to discover and request licenses for all SaaS applications used in your organization and request applications from Zluri's market's largest library of applications.

Admin can enable the Employee App store for employees by toggling the highlighted toggle bar field at the top right corner.

You can configure- it from the "Employee App Store" option on the Settings page.

●      Which applications within your organization will be visible to your employees. 

●      What information about these applications will your employees be able to view.

●      Choosing the authorization level to define applications that are part of your organization. On selecting "Show Unmanaged Apps," an employee can view all the unmanaged applications in the organization.

Depending on your organization's internal security compliance and application provisioning process, you can configure the settings here accordingly.

Some example scenarios -

●      If your organization needs employees to see only the applications used within their department, which they can then request licenses for, you can choose "Employee Department Apps."

●      If you only need your employees to see applications that your IT admins have categorized as "managed" apps within Zluri, you can turn off the options to show unmanaged, restricted, and uncategorized apps

●      If you do not need your employees to see security and compliance information about a particular application within the app store, you can turn off the options to show security information and compliance.

While employees can still search for, find information about, and raise requests for ~225k applications within Zluri's library, configuring these settings upfront will ensure employees see only the information they need to see about the IN USE applications within your organization.

A unique feature of access management is the branding of the organization. Both logo and the favicon can be uploaded.

Configuring Automation Rules for Approval Workflows

Automation rules help your employees' license and application requests go through the appropriate approval processes followed within your organization. 

Automation Rule Sections

To set up an Automation Rule, click on App Requisition - -> Automation Rules--> New Rule.

An automation rule consists of five sections:

Request Type:

Suppose your organization has different approval processes for applications already in use (License of an Existing Application is Requested) and not used (New Application is Requested) by your organization. In that case, you can use this option to differentiate the two.

Conditions:

You can customize your approval workflows by creating multiple automation rules with different conditions. Sample scenarios -

●      Users who have a "Manager" designation and users who have an "Associate" designation.

●      Users with an "Employee" account type and users with a "Service" or "External" account type.

●      Members of the "Sales" or "Marketing" department and members of the "Engineering" department.

You can differentiate the approval processes using different conditions in different automation rules for these above scenarios and much more.

Actions:

For a specific request that fits the request type and conditions specified above, you can set up the rule to either initiate an approval process that'll go through a list of approvers you've configured or automatically reject the request.

Approvers:

For requests not auto-rejected, you can select one or more approvers responsible for reviewing the request and approving or rejecting it accordingly.

You can assign specific roles as approvers - the default dropdown when you "add people" will contain a list of roles configured within Zluri, such as IT admin, app owner, department head, and reporting manager.

This is helpful in scenarios when the user's reporting manager or department head needs to approve each request before it moves onto a different approver. Alternatively, specific individuals can also be searched for and added as approvers.

Configuring this section is mandatory for a rule to be saved.

Provisioning and de-provisioning actions:

Once a request is approved, the license needs to be provisioned to the user, which can be configured in the "On approval" section. And once the requested license duration is completed, the license de-provisioning process can be set up in the "Offboarding action" section.

In both scenarios, the setup is very similar. The provisioning and de-provisioning actions can be configured as a manual task - select a task owner who'll be notified to procure a license once the request is approved (in case of provisioning) or remove license access once the duration has ended (in case of de-provisioning), and specify within how many days the task has to be completed.

The "on approval" section configuration is mandatory to save a rule. "Offboarding action" is optional.

After entering all the above-required details, the automation rule can be saved that will look like this: 

Automation Rules Priority

When multiple rules are set up, they can be arranged in decreasing order of priority. For example, if two rules have similar conditions and different approvers are involved or other provisioning/de-provisioning actions are configured, the rule with the higher priority takes precedence.

Automation rule setup best practices

●      Identifying your organization's current approval process broadly can help set up a few basic rules that can serve most of your employees' application requests while giving the admins enough context to customize the rules even further.

●      Ensure all roles, either Zluri administrator roles or roles that differ from one app to another (app owner) or one employee to another (reporting manager or department head), are comprehensively configured(under Users and Department sections) so that the approval process does not run into any obstacles.

Approval Process

Once an employee submits a request, approvers will be notified in a sequential order to approve or reject the request.

If an approver is unavailable, admins can add new approvers to this request to take this action in place of them, or the admins can approve or reject the request on behalf of the approver.

One can click on the three dots for an application to view the submitted request.

On clicking the View Request, an employee/approver will be able to view all the details necessary for him to approve or reject the request and also some other information (like View Change log, The app is used in the org or not, Other approvers for this request, offboarding actions, request due days, comments by others) which is highlighted in the below screenshot:

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 can also add comments explaining why the particular request was rejected. 

Admin Actions

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 specific 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 -

2. 
   

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

3. 
   

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

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

Reject on behalf of an approver

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

2. 
   

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

3. 
   

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

4. 
   

   1. The status of the request changes to "rejected" on the "All Requests" page.

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

Override rejection

Admins will 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.

Add New Approvers

In the process, there is also an option to add new approvers to 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.

Role Based Approvers

We have the 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 reflected on the "request summary" page.

Provisioning and De-provisioning

Once all approvers approve a request, the task owner will be notified to add the user(s) to the application, post which they can mark the task as completed.

Doing this will ensure that the employee is added to the application's list of users and that the assigned license is also mapped to the user for the admins to monitor going forward.

Changelog

The employee has to keep track of the changes in this process. Hence Zluri introduces a change catalog. 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. 

Click on View Changelog to view the details: