Skip to content

Access Request Overview

Limited Availability

Opt in to enable the latest Access Request UI for your tenant.

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 human and machine identities 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 a form as required input when requesting access to a given access item.
  3. 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.
  4. Define segments if you need to restrict who can submit access requests for certain items.
  5. Specify whether users can make requests for others in addition to themselves.
  6. Specify whether users can request access for machine identities when they submit machine account requests. Organizations must have Machine Identity Security and Agent Identity Security to submit these requests.
  7. Set global site settings like email reminders and escalations for the review process.

Note

On the Approvals page, the detail information about each access request approval includes an Identity tab with the identity's name, email, manager, and identity state. You can use the Update Public Identity Config endpoint to add up to 5 additional attributes, giving the approvers more information about who they are reviewing access for.

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, some can submit requests for others, and some can submit requests for machine identities. If the human or machine identity that a user is requesting for has multiple accounts on a source, the requester will select the account that needs access. Requests can optionally require requesters to complete a form and may also include an expiration date for the access.

  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 identity the access was requested for to help the reviewers make their decisions.

    Note

    By default, the human or machine identity'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 assigned or provisioned.

    If the request is for a Just-In-Time assignment, rather than standing access, the access item is assigned, which means that it is made available to the user to activate from their Launchpad > Just-In-Time Access page. Access is automatically deprovisioned when the Just-In-Time session expires. Refer to Activating a Just-In-Time Entitlement.

    If the request is not for Just-In-Time access and an optional access start date was selected, the access item is provisioned on that date. This may be used to schedule access for pre-hire or job change processes or to schedule a future project start date. If a start date was not specified, the access item is provisioned right away.

    The human or machine identity retains this access until the access expires, is deactivated (in the case of Just-In-Time access), or is revoked.

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

    If SailPoint Human Fabric 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.
    • Requests submitted through SailPoint Human Fabric'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.
    • By default, requests that have not been fully approved after 90 days will be automatically denied and expired. You can configure a shorter expiration duration, and for expired requests to be automatically approved using the timeoutConfig attribute on the Update approvals configuration endpoint.

    If SailPoint Human Fabric 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.

Requesting Access Using Harbor Pilot

If Harbor Pilot has been enabled by an administrator, you can select the Harbor Pilot icon and enter a natural language request for help submitting and managing access requests. Depending on your tenant's settings, this icon appears as or . Refer to Using SailPoint Harbor Pilot for more information.

Caution

Harbor Pilot has some limitations and can make mistakes. As SailPoint receives more feedback, Harbor Pilot will continue to evolve.

Using Policy to Control Access Request Approvals

You can use policies to govern access request approvals. Once an access request policy is enabled, each access request that is submitted is evaluated against it. Any request matching the policy criteria will generate an outcome as defined in the policy. If no policies match, the policy engine has no effect on the approval flow and the access item's configuration is used. Access revocation requests are not evaluated against policies.

If multiple policies match with the request, all will be evaluated and one final decision is returned, generally the most restrictive. Refer to Policy Center Overview for details.

Policy decisions are nearly always favored over static access request configurations. An exception is when any policy matching a request is configured to honor the existing access request configuration. In that case, the final decision from the policy center is to honor the existing configuration.

Note

Access request policy evaluations do not apply to bundled provisioning access requests, dynamic role requests, or if a tenant has globally disabled approvals. They also do not apply to access requests made via the ServiceNow plugin.

To create or edit an access request policy:

  1. Admins and Access Request Administrators can go to Admin > Policy Center > Administration.
  2. From the left navigation, select Access Request.

  3. Select + Create Policy.

    • To edit an existing policy, select Actions > Edit on its row.

  4. On the General Details page, enter or update the following information about your policy:

    • Basic Information

      • Name - Name of the policy.
      • Description - Describe the policy.

    • Ownership

      • Owner Type - Individual or governance group.
      • Policy Owner - Use the dropdown to select who is responsible for this policy.

  5. Select Next.

  6. On the Match Criteria page, define criteria by choosing which subjects and attributes or contexts will be evaluated in this access request policy.

    • Select Add Criteria to add more criteria, up to 5 criteria per group, and Add Group to add more groups, up to 3 groups per policy.
    • You can use the And/Or toggle for criteria within groups and between groups.
    • Use the Case sensitive checkbox to indicate values that need to match case as well as content.
    • To remove an item from the list, select the Delete icon next to it.

  7. Select Next.

  8. On the Match Handling page, use the dropdown to select the Decision that will be applied to access requests matching the criteria you have defined. Options include:

    • Honor existing configuration - No additional configuration is needed on the Match Handling page. Refer to Configuring Access Requests.
    • Automatically approve - Automatically approve requests that match the criteria.
    • Automatically deny - Automatically deny requests that match the criteria. No additional configuration is needed on the Match Handling page.
    • Trigger adaptive workflow - Select the workflow you want to trigger when criteria are met. Optionally, you can choose to require the approver to reauthenticate when taking action on a request.
    • Require approval - Select approvers for requests that match the criteria. Optionally, you can choose to require the approver to reauthenticate when taking action on a request.

  9. Select Next.

  10. On the Test Impact page, try a simulation of your policy.

    Note

    When testing the impact of a given policy, only that specific policy is evaluated. Any other potentially applicable policies are ignored for the duration of the test.

    • Select an identity and add test attributes.
    • Use the toggle to select whether to simulate a requester that is different from or the same as the recipient.
    • Select an access item type and any additional attributes.
    • Select Run Simulation.
    • Evaluate the results, including a per-criterion breakdown. You can expand to view which criteria did or didn't match the selected inputs. Select one of the previous pages from the left navigation to make changes to that information.

  11. Select Save to save the policy in an inactive state.

  12. Select Close to close the policy builder.
  13. The new policy appears on the Access Request Policies page. Enable it by selecting Actions > Enable.

Managing Access Request Policies

The Access Request Policies page includes a list of all policies by name and includes owner and status. Find policies by scrolling or searching by name. Use the dropdowns to filter the list by status (enabled or disabled) or owner.

Admins and Access Request Administrators have the following options available in the Actions column for each policy:

  • View Details - Including description, owner, match criteria, match handling, approvers, and status.
  • Edit - Update the policy.
  • Duplicate - Create a duplicate policy.
  • Disable/Enable - Enabled policies are actively applied to access requests, disabled policies are listed on the Access Request Policies page and can be edited, but are not applied to access requests. Policies are disabled by default; enabling a policy is a manual action.
  • Delete - Remove the policy from your tenant.

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, SailPoint Human Fabric 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.

Reviewing Access Request History

You can review the history of access requests and their approval decisions through search by querying Event records.

Use the search string “Request Access” (include the quotes to search for both words together) to see a number of different event records related to access requests. Add additional criteria to narrow down your search to specific actors or access recipients. Search for events that include a specific user by adding either && or AND, then the username. For example, to search for access requests associated with user Alice.Carter, enter “Request Access” && Alice.Carter.

Search results include events such as:

  • Request Access Started – The original submission, including who requested what for whom.
  • Request Access Approved – User who approved the requested item for the user.
  • Request Access Rejected – User who denied the request.
  • Request Access Cancelled – User who cancelled the request before the approval or processing was finished.
  • Request Access Processed – The actual provisioning of the item.

Search records also include Request Access Escalated, which lists the new owner of an escalated request. This is not listed by access recipient, but if the new owner completes the approval you can trace the request to a Request Access Approved entry.

By default, the event records display the action as named above, the Actor who completed the action, the Target who the action was focused on, and a timestamp of the action. Use the Column Chooser icon to customize your view. Adjust the columns to display Details and Source Name so your search results will include item name and source.

Select the Download icon to export search results to a CSV for offline analysis, sorting, and filtering.

Documentation Feedback

Feedback is provided as an informational resource only and does not form part of SailPoint’s official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.