Access request conditions
Early Access release. See Enable self-service features.
Creating access request conditions is a two-step process. You must be a super admin or an admin with both access requests and app admin role assignments to perform this process.
- Configure access request conditions.
Define who can request access. Specify the access level that they can request and how long the access should be granted. When the access request expires, the user's access is automatically revoked.
Set up an approval sequence that governs the information a requester or approver needs to provide. An approval sequence is a series of steps (questions, approval tasks, and custom tasks) that the user must complete before the next one is initiated. For a requester to get access, they must complete all tasks successfully with all approvers granting approval.
Define who should approve or deny the access request.
- 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.
If you change a group name or description, you must disable the conditions that include that group, and then enable them again for the change to take effect. See Re-enable a condition for group changes.
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. Private requests are visible only to admins, the people directly involved in the request (like assignee, task assignee, requester, and follower), and the members of the team on the request.
-
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.
-