Request types
A request type is a customizable no-code approach that defines how an access request is processed.
Every request type is made of one or more steps. The complexity of an individual request type varies: a simple usage might automatically add a user to a group, while a more advanced usage might need approvals and justifications from multiple stakeholders.
Combine multiple steps if you need to define a chain of events that must happen before a request completes. For example, a request might need approval from multiple departments. Each approval would need a separate approval action from a different stakeholder. Combining multiple steps into a single request type gives oversight and accountability into how and why a request is approved. It simplifies the decision-making process by giving you the total context of the request.
Access requests teams create and own request types and the team is responsible for maintaining them. Request types allow organizations to create a comprehensive service library to meet user and organizational needs.
- You can't use request types to streamline access requests for admin roles. See Govern Okta admin roles and Access Requests for admin roles instead.
-
If you're new to Access Requests, use conditions to manage access requests first.
Components
Access Requests uses a combination of the following components:
| Component | Description |
|---|---|
| Request | A record of a user's request 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. |
|
Steps |
A step is an item that you can add to a request type, such as a question, task (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 |
Resources are synced directly from your integrations. 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.
|
|
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:
|