Access request conditions

Early Access release. See Enable self-service features.

If you're a super admin or another admin with both access requests and app admin role assignments, streamlining requests using access request conditions is a two-step process:

  1. Configure access request conditions:
    1. Define who can request access, specify the access level that they can request, and how long the access should be granted for. When the access request expires, the user’s access is automatically revoked.

    2. Set up an approval sequence that governs the information a requester or approver needs to provide and define who should approve or deny the access request.

    3. An approval sequence is a series of steps (questions, approval tasks, and custom tasks) that occur in a sequential order where the user must complete each step before the next one is initiated. For a requester to get access, they must complete all tasks successfully with all approvers granting approval.

  2. Enable the condition.

After you enable a condition, eligible requesters can request access from their dashboard. They can select from the available apps, enter the required information, and submit the request. Once they submit a request, the approval sequence is triggered and approvers are assigned and notified that they have a task that needs an action from them. After the approvers complete their tasks, users are granted or denied access automatically based on the approver’s decision.

In a situation where a task in the request gets unassigned, the request assignee for that request can manage the request from the Okta Access Requests web app.

Considerations

If you’re already subscribed to Okta Identity Governance, requests managed by conditions are different from requests managed by request types. Here’s how requests managed by conditions differ:

  • Okta marks these requests as private by default and you can't change the privacy setting.

  • You can’t view or edit these requests using the Access Requests public API.

  • Certain functions like Okta actions, automated tasks, integrations with Jira, and ServiceNow aren’t available.

  • Requester experience:

    • They can’t request access on behalf of another user.

    • They can't reopen requests.

  • Request assignee experience:

    • Only super admin and access request admins can manage these requests. Okta automatically sets a super admin or an access request admin as the request assignee. You can change the request assignee to another super admin or an access request admin.

    • Request attributes like Team and Request Type aren’t visible on the Request details view.

    • When a step is assigned to a group, changes to the group that occur after the request aren't synced. For example, an admin added to an approval group after a request is submitted can't approve the request.

Next step

Create an access request condition