Access Request Overview

Users can submit access requests to get access to the applications or business roles they need to perform their jobs. As an administrator, you’ll set up access requests for users and configure approval processes for these requests.

Configuring Access Requests

Complete these tasks to configure access requests for your site. These configurations impact system behaviors, user options, and data in the access request process.

1. Configure which items can be requested from your roles, access profiles, and entitlements.
2. Set each item's required approval process. For roles and access profiles, set the approval process individually for each. For entitlements, set the global configuration and optionally specify overrides per entitlement.
3. Define segments if you need to restrict who can submit access requests for certain items.
4. Specify whether users can make requests for others in addition to themselves.
5. Set global site settings like email reminders and escalations for the review process.

Understanding Access Requests

The access request process includes these key steps.

1. Users submit access requests.

   Users can submit access requests to obtain access to entitlements, roles, and application access profiles. All users can make requests for themselves.They may also be able to request for others. Requests can optionally include an expiration date for the access.

   Note

   If you are using the legacy Request Center, you can opt into the updated experience using the provided form.

2. Reviewers approve or deny access requests.

   If access requires approval, reviewers review the access requests submitted by other users. The requests include details about the user the access was requested for to help the reviewers make their decisions.

   Note

   By default, the user's display name and their manager's email display in the Identities tab. You can add up to 5 additional attributes using the Update Public Identity Config endpoint.

3. If approved, the access item is provisioned.

   The user retains this access until the access expires or is revoked.

4. If an expiration date was specified, IdentityNow initiates revocation as scheduled.

   If IdentityNow is directly connected to the source system, the access is automatically deprovisioned.

   Notes

   • The expiration date is not sent to the source system as an account attribute.

   • The Request Center supports specification of expiration dates but not times. On the specified date, IdentityNow triggers the deprovisioning process at 12:00 AM in the time zone set on the requester’s browser.

     • Requests submitted through IdentityNow's API using the Submit an Access Request endpoint can include a time component as part of the removeDate attribute to control the deprovisioning time.

   If IdentityNow is not connected to the source system, a manual task to remove this access is created and assigned to the source owner. The source owner removes this access in the source.

Troubleshooting Access Requests

A user submitted a request but it does not appear in their My Requests list.

When a request encounters an error that prevents it from being processed, the requester receives an email notification, and the request is not included in their My Requests list. For example, the user may already have the requested access or have multiple accounts on the source.

An access request's Account Activity record in Search contains the warning, "Delayed provisioning due to an existing provisioning request for creating an account on the same source with the same nativeId."

When a user does not have an account on a source where an entitlement is requested, IdentityNow will automatically create the account. If multiple entitlements are requested on that source for the user at or around the same time, only the first entitlement is turned into an account creation request. Provisioning for other entitlements is paused until the account creation request completes so they can be added to the new account through update operations.