Access Request Workflow Skip to main content
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Access Request Workflow
Published: Sep 14, 2017   -   Updated: Jun 22, 2018




Access Request Workflow

This is an Early Access feature. To enable it, please contact Okta Support.

The Access Request Workflow feature is a complete, multi-step approval workflow through which end users can request access to apps. Admins can designate approvers to grant users access for self-service applications.

This feature enhances Okta's provisioning solution, which typically is used by IT teams to automate account provisioning and SSO access for users on their first day of employment. Later, users need access to job-specific applications that are often beyond an IT team's purview. The Access Request Workflow feature allows business application owners — rather than IT — to grant users access to apps and assign entitlements in apps that require them.

Use Access Request Workflow to:

  • Designate group and individual approvers
  • Create customize notifications
  • Add comments and notes
  • Configure customizable timeout rules

You can do all of this from the Okta Admin Dashboard. No programming or configuration files are required.

End User Experience

End users are shown a list of apps when they click Add Apps. Apps that do not require approval have an Add button; apps that do require approval have a Request button. Clicking Request opens a window through which users confirm their request. Users can enter an optional message to the approvers of up to 1,000 characters. Confirming the request changes the Request button to Requested. During the approval process, end users receive the messages and email notifications that you configure.

Approver Experience

After users request an app, the first approver receives an email containing the request and a link. Following the link gives options to approve or deny the request.

  • If you approve the request and you are the first approver in a chain, the next approver receives the email message.
  • If you approve the request and you are the final or only approver, the user is provisioned to the app and receives SSO access if the app is configured for provisioning; otherwise, the users is assigned to the app and receives SSO Access.
  • If you deny the request, the user is not granted access and the system log is updated.

In all cases, only the messages you enable in the setup are sent.

Approvers can check outstanding approvals in their queue at any time through their Okta Home Page by selecting the down arrow next to their user name and then selecting Tasks. Approvers can process any approvals from the list.

Group Approver Experience

If a group is specified as an approver, all members of the group receive email notifications and are asked to approve the request. When one member of the group approves or rejects the request, the step is complete, and the task is removed from all the other group members' queues.

Admin Experience

After the approval is set up and an end user requests an app, Okta Admins can intervene in the approval process and perform any of the following actions:

  • View outstanding requests and see the current step of the approval process.
  • Resend approval notifications to the current approver.
  • Cancel an outstanding request.
  • Override this process and assign the app to an end user immediately.

To view, resend, or cancel a request

  1. Go to Applications > Applications.
  2. Click the Assignments subtab.

  3. Click Manage Requests. This button is shown for requested apps, below the self-service configure option.

    In the Manage Application Requests window you can:

  • View the request history. Click the > icon.
  • Resend the request. Click the paper airplane icon.
  • Delete the request. Click the trash can icon.

Note: If you override the approval process and assign the app immediately, the approval process stops. The user can access the app, and any existing workflow is deleted.

Admin Best Practices

Certain admin actions can have an adverse effect on Access Request Workflows. Doing any of the following can cause issues with existing and subsequent access requests.

  • Deactivating the app
  • Deactivating an approver
  • Deleting a group specified as a group approver
  • Modifying the schema of an app

Before making any of these changes to applications or approvers, take action on any affected requests that are pending, and then disable approval for the app. After you make changes, you can enable approvals for the app again.

Configure your org for Self Service
  1. Go to Applications > Self Service.
  2. In User App Requests, click Edit.
  3. Ensure that either Allow users to add org-managed apps or Allow users to add personal apps is selected
  4. You can also select Allow users to email "Technical Contact" to request an app. Before selecting this option, make sure that you have configured the email alias of the Technical Contact in Settings > Accounts > End User Support.
  5. self-service-new1

Configure the App Approval Workflow
  1. Go to Applications > Applications and select the name of the app.
  2. Click the Assignments subtab.

    Note: This tab is not the Assign to People link in the app setup.

  3. Click Edit in the Self Service section in the sidebar that appears on the right.
  4. Specify whether you want to allow users to request this app.
  5. self-service_new2

  6. If you choose to allow users to request the app, you also need to configure the following:

    • Note for requester — Use this field to provide a description of the app or instructions for the requester. The maximum length is 500 characters.
    • Approval — Either Required or Not Required. You can always configure approval and then make it required later.


  7. If you decide to configure the approval flow, then use the following options:

    • Send app requests to — Specify the individual or group that should receive the app requests.

      To specify an individual, begin typing the individual's name. A list of matches appear from which you can select.

      To specify a group, change the drop down to Group and then type the group name. Groups designated as approvers cannot contain more than 100 members.

      You can specify multiple individuals or groups to create an approval chain. An approval chain cannot exceed 10 approvers.You cannot enter the same individual or group more than once.

      Entitlements specify the action the approver can perform on the requester's account. There are three choices.

      • Hidden — approver cannot view user's account attributes
      • Read — approver can view, but not modify, account attributes
      • Write — approver can edit the requester's account attributes

      Best Practice: Set up the approval chain to satisfy provisioning requirements.

      • If the app supports provisioning and has required attributes that need to be specified during assignment, then at least one of the approvers needs to be able to edit and set these user attributes.
      • If the app does not support automated provisioning, the final approval step can also serve as the provisioning step. Select an admin who can provision the application account as the final approver. This admin can provision the account and then approve the request to give the end user immediate SSO access to the app.

      Note: To change the order of the approvers, click and hold the dotted handle to the left of the approver's step number and drag the line to the desired location.


    • If request is approved — Specify any actions in addition to the notice the requester received when the app is added to the Okta dashboard. If you choose Send email to others, you are prompted for an email address.
    • Approver must respond within — Specify how long each approver has to respond to the request. You can specify 1 week, 30 days, or a custom time period.
      • When a request times out, Okta cancels the request. Okta does not grant the user access to the requested app. Requests that time out are marked differently in the Okta logs than requests that are explicitly denied.
      • The configurable timeout applies to each step in the approval chain. For example, if an admin chooses 1 week for the approval time, each approver is given a week to respond, if there are multiple approvers. If there are three approvers, the total chain could potentially take three weeks to approve.
      • Timeouts can be used to define a service-level agreement (SLA) for requests and handle situations in which an approver is not available for reasons such as leave or vacation. Okta recommends that you notify your support organization about timeouts so that they can follow up with the requester and manually fulfill the request if needed.


  8. If you have not set the app to show in the self-service settings, the following message appears after you click Save. Follow the link to edit the settings and check the Show column for the app.


Disable methods that end-users can use to request apps

You can disable the various methods that end users can use to request apps.

  1. Go to Applications > Self Service.
  2. Click the Settings tab.
  3. In Permissions, make sure Allow users to email "Technical Contact" to request an application is not selected.

When you disable this option (by deselecting it), these end user options are unavailable:

  • The Contact button that appears in the end user app search field. Screenshot


  • The Request an app link in the Okta footer. Screenshot


  • The Request app option in the Add Bookmark dialog box. Screenshot


System Log Entries

Workflow events are tracked in the System Log. The following items are tracked:

  • User app requests – the requester's comment is logged in the System.DebugContext.DebugData section.
  • Individual approver approvals and denials – the approver type is logged as USER and the approver's comment is logged in the System.DebugContext.DebugData section.
  • Group approver approvals and denials – the approver type as is logged as GROUP and approver's groupId, group name, and comment are logged in the System.DebugContext.DebugData section.
  • App approvals* – when all approvers have approved the request and app access is granted to the user.
  • App denials* – when an approver has denied the request and app access is denied to the user.
  • Request deletions – when the user's request for an app is deleted.

*Note: These items are triggered by the Okta system granting or denying access, not by actions of an approver.