Identity Governance and Administration

Access Requests

  • Zluri Employee App Store - How-to Guide


    The prerequisite for using the Employee Appstore feature is to set up a SAML login. Please take a look at the below links for the same.

    Generic Steps to Setup SAML 

    SAML App Addition - OneLogin

    SAML Okta

    SAML Jumpcloud

    SAML Google

    App Store Settings Configuration

    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.






    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.




    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.




    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 -

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

      1. 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.

    Reject on behalf of an approver

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

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

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

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

    2. 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.


    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:

Access Reviews

  • Access Reviews Module-User Guide

    Table of Contents


    Access Review Roles and Due Dates    


    Due Dates    


    Creating a Deprovisioning Playbook    

    Access Review Process    

    Creating a Certification    

    Reviewing a Certification    

    Conclude Review    

    Complete Certification    

    Additional Functionality    


    Access Reviews is a critical process performed by InfoSec teams to ensure that the access granted to users for each application within an organization’s tech stack is accurate, appropriate, and aligned with security and compliance policies.

    Zluri’s Access Reviews module facilitates this process in a streamlined and efficient manner, providing centralized visibility into all applications that require review while offering detailed information necessary for these reviews. With Zluri, users can manage multiple app reviews efficiently, assign reviewers, and implement post-review actions.

    Access Review Roles and Due Dates


    • Primary Reviewer: Responsible for reviewing access certifications, verifying, and taking actions such as approving, rejecting, or modifying access.

    • Fallback Reviewer: Assigned as the reviewer if the primary reviewer is unavailable or not correctly configured.

    • Certification Owner: Validates access reviews, ensures completion of the review process and oversees actions taken based on reviews.

    Due Dates

    • Review Start Date: The Certification can be viewed in two sections based on the Start date: Ongoing Certifications and Upcoming Certifications.

    • Review End Date: Reviewers with pending reviews will receive alerts, along with the certification owner.

    • Remediation End Date: The certification owner will be notified to finalize any pending remediation actions and tasks.


    Before initiating access reviews, ensure the following:

    • Necessary roles must be set up to assign appropriate responsibilities and permissions for conducting access reviews efficiently.

    • Deprovisioning app playbooks must be configured to automate actions for revoking or modifying access based on review outcomes.

    • Required integrations must be connected and scoped properly to enable automated workflow actions during the access review process, ensuring seamless execution of tasks across applications.

    Creating a Deprovisioning Playbook

    1. Navigate to the desired application on Zluri.

    1. Navigate to Automation > Deprovisioning tab and click Add to create a new playbook. 

    Note: Next, a pop-up window will appear, displaying all available de-provisioning actions.

    1. Add de-provisioning actions, ensuring integrations are connected. 


    • If the integration is available but not connected, you can see it listed. Clicking on the integration name will redirect you to the connection screen.

    • Once the integration is connected, you can select the instance and choose the automated action to remove or downgrade user access.

    1. You also have the option to convert the action to a manual task by clicking Convert to Manual Task if integration is not desired.

      1. Choose a template, add details, and save changes to publish the playbook.

    2. After configuring the necessary actions for access revocation or downgrade, click Publish appPlaybook to create the playbook.

    3. To view the published Deprovisioning Playbook, click View Runs or navigate to the Runs tab from the sidebar menu.

    Access Review Process

    Creating a Certification

    1. Navigate to the Access Review tab and click Create New Certification.

    2. Provide the following Certification Details and click Next.

    • Certification Name

    • Certification Owner

    • Description (optional)

    1. Complete the following Set Up Certification.

      1. Click Add Application to select Applications to include, and click Next.

      2. Specify Reviewers (Primary and Fallback) and click Next.

      3. Choose Users for review using relevant filters and click Next.

      4. Select Data Columns for reviewer visibility and reference and click Next.

      5. Configure Actions for review status (rejected or modified) using pre-configured de-provisioning playbooks and click Save Application.


    • Upon clicking Save Application, you will be directed to the Set Up Certification page, where additional applications can be added.

    • Users can modify or delete the added application by selecting the edit or delete icon.

    1. Upon adding the applications, click Next.

    1. Complete Setup for the access certification.

      1. Specify the Review Start Date and End Date.

      2. Specify the Remediation End Data and click Create Certification.

    Note: The automated reminders will be sent 48 hours before the due dates to the associated users.

    Reviewing a Certification

    Reviewers can access ongoing certifications and take actions on user access (approve, modify, revoke).

    1. Navigate to the Access Reviews > Ongoing tab to view the open certifications list.

    2. Find and click your certification name to open its dashboard page.

    3. Click on the application name to view review details in a sidesheet.

    Note: The reviewer and the certification owner can approve, remove or modify access by clicking on the actions icon for the users.

    1. Review user details and take actions (approve, remove, modify) as needed.


    • For removal or modification of access, it is neccessary to add comments for actions taken as it creates a record for audit purposes and can be referred to in the report.

    • Reviewers can select multiple or all users and select Bulk Review Action or Delegate Review from the Bulk Edit drop-down.

    • Reviewers cannot review their own access.

    Conclude Review

    • Upon review completion, close the side sheet and click Conclude Review on the dashboard to run the actions.

    Note: App playbooks configured earlier will run automatically based on review actions.

    Complete Certification

    1. Validate the results of executed actions and click Complete Certification to mark the certification as completed.


    • A detailed PDF report is generated and sent to the certification owner.

    • All the certifications marked as completed will be available under the Access Reviews > Completed tab.

    Additional Functionality

    • Notifications: Automated notifications are sent to reviewers for pending reviews and upcoming deadlines.

    • Cloning Campaign: Clone previous certifications to reuse configurations for similar reviews from Certification dashboard pages from Ongoing or Completed tabs.

    • Show progress by reviewers: The certification owner can now see the progress for each reviewer assigned to an access review campaign and send reminders to specific reviewers or all reviewers who have pending reviews to complete.

    • Employee View: Employees (app users) can view and take action on certifications assigned to them as reviewers.

Can’t find what you are looking for? Let us help you!

Identity Governance and Administration