Access Requests

Directly integrated into an Okta organization, Access Requests automates the process of requesting access to applications, groups, and entitlement bundles. Expanding on Okta's existing self-service offerings, Access Requests delivers a simplified and frictionless approach that automatically routes user requests to one or more approvers for action.

This allows Access Requests to eliminate the challenges common in more traditional workflows:

  • Poor request experience
  • Risk of human error
  • Decreased IT productivity
  • Complex and rigid workflows
  • Audit and compliance deficiencies

To streamline access requests for admin roles, see Govern Okta admin roles and Access Requests for admin roles instead.

Govern Okta admin roles might not be available for you depending on your org's eligibility. Contact your account executive or customer success manager for more information.


Access Requests meets the needs of several different organizational roles.

Role Description
Requester A requester is any user who requests access to a resource and is assigned the resource after the required steps are completed. Requesters want to quickly request access to specific resources using common productivity tools such as chat or web.

Users must be assigned to the Okta Access Requests app for them to create requests or be available to reference them in Access Requests components.

Request creator

If a user submitted a request for someone else, they’re referred to as the request creator. The person they requested the access for is the requester. The requester is the user who ultimately receives the access to the resource.

Approver Approvers need clear visibility and context for requests, so they understand what to approve and for whom.

Approvers need to review approvals using common productivity tools such as chat or web to improve efficiency and resolve requests quickly.

Admin Admins want to construct unique, no-code blueprints that ensure that stakeholders take appropriate actions before completing a request.

Admins want to orchestrate automated request fulfillment so teams aren’t responsible for managing low-risk access requests.


Access Requests uses a combination of the following components:

Components Description


A request is a record of a user’s ask for access to a resource. Each request is associated with a request type. Requests follow the steps that you define in the request type for the resource.

It contains details like the request creator, requester, status, messages, and more.

Access Requests Teams Use teams to organize users into logical groups within Access Requests. See Create an Access Requests team.

Teams can create request types and manage any associated requests.

You can also associate one or more teams with a request type to allow those teams to manage the request type and incoming requests for that request type. Okta recommends that you use groups instead of teams for handling approval tasks within a request type.

Add a team to a resource to use the resource in automated tasks.

Request Types A request type defines how an access request is processed. Each request type is made up of one or more steps. These steps are routed to the appropriate assignees for review after a requester submits a request.

Access Requests teams create and own request types. See Request Types.


A step is an item that you can add to a request type, such as questions, tasks (custom, approval, or action), and timer.

Questions and tasks are the steps that you can assign to users to complete. When you assign a step to a user, Access Requests sends a notification to the step assignee.

Audiences Audiences control which users can submit a request with a specific request type. Audience members can also request access on behalf of their fellow audience members.

Teams can make request types available to everyone, or limited to specific Access Requests teams or Okta groups.

Request assignees Assignees manage a request after it’s submitted and are always members of the Access Requests Team that owns the request type.

Assignees are responsible for reassigning individual tasks or approvals to ensure that the request is quickly completed.


Resources are synced directly from your integrations. Currently, Access Requests can sync resources from Okta, Jira, and Service Now.

You can create a configuration list from a resource and use it in a request type. You can't modify a resource from the Access Requests Console.

By default, Access Requests syncs with the associated Okta org and creates resources, such as Applications, Okta groups, Okta Workflows, and entitlement bundles.

  • The Okta Workflows option is only available in the Access Requests console if you have enabled the Okta Workflows actions in Access Requests and Assign admin roles to apps features for your org, and assigned Okta Access Request OAuth app as an admin. Okta Workflows actions in Access Requests is an Early Access Feature. To learn how to enable it, see Enable self-service features. Also, see Before you begin.
  • Entitlement bundles are available only if Governance Engine is enabled for an app and the admin has created entitlements and entitlement bundles for it. See Get started with Entitlement Management.

Configuration lists

Configuration lists are customized collections of resources or admin-defined values. They determine which applications or groups that a team can use in a request type. Use them in request types to specify options available to your end users or control how automated actions work within a request type.

You must create separate configuration lists for each resource type.

For example, while creating a request type, you want to make some groups available for admins to assign to requesters. In addition, you want to make some applications available for a user to request. In this case, you must create a configuration list for applications and another one for groups.

There are two types of configuration lists:

  • Resource lists

    Resource lists are configuration lists that you create from resources. To automate access to resources, create resource lists and reference them in request types.

    For example, you want your end users to only be able to request access to applications available to their specific Okta groups. You can create a resource list, which includes the applications that are available to your end users. Next, reference the resource list in a request type and configure the request type to be available only to members of specific Okta groups.

    You can’t create a Okta Workflows-based resource list.

  • Custom lists

    Custom lists are admin-defined lists of values that you can reference in a request type. These aren't associated with a resource. Use custom lists to better meet the needs of your organization.

    For example, a team creates a custom list that lists available laptop models. When a requester submits a laptop request, they can select one of the available models as they make the request.