Access requests

Understand the tool scopes, features, and capabilities for access requests, with sample workflows and example prompts.

Early Access release

Tool name: okta_identity_governance
Okta scopes: okta.governance.accessRequests.read, okta.governance.accessRequests.manage, okta.accessRequests.request.read, okta.accessRequests.request.manage, and okta.accessRequests.catalog.read

What you can do

Create and manage access request types, submit and track requests, and configure request conditions.

Request types

List, retrieve, create, publish, unpublish, and delete access request types
List teams that can administer request types
List and retrieve catalog entries for access requests, including entries that are visible to a specific user
Retrieve the form fields that a user must complete to submit a request for a catalog entry

Access requests

List and retrieve access requests in your org
Submit a new access request on behalf of a user
Post a message on an existing access request
Supports both V1 and V2 request formats with automatic routing based on token scope

Request conditions and settings

List, retrieve, create, update, activate, deactivate, and delete request conditions for a resource
Retrieve and update org-level and resource-level access request settings
List, retrieve, and delete approval sequences for a resource

Key features

Supports V1 and V2 request formats with automatic server-side routing
Cursor-based pagination for list operations
Reduce LLM token usage with token-optimized TSV responses
Operations are dynamically filtered per request based on the bearer token's granted scopes

Use case	Prompt	Result
A new manager is joining the team. The admin wants to put an onboarding access path in place so requests for the new joiner flow through manager approval from day one. The admin wants the supporting group created and the request type made live immediately so employees can start using it right away.	Set up an onboarding workflow: first create a group called Engineering Onboarding. Then create an access request type named Engineering Onboarding Access targeting that new group. The request type is owned by the IT Operations team, with manager approval, active immediately.	A new group is created, then a linked access request type is created and activated with manager approval.
The admin wants a stronger approval process for a sensitive group. Both the resource owner and the requester's manager have to sign off, instead of relying on manager approval alone.	Create an access request type named Sensitive Group Access, owned by the Security team, targeting the Finance-Confidential group. The approval chain requires the resource owner to approve first, then the manager.	The access request type is created with a two-step serial approval chain: resource owner approval followed by manager approval, giving stronger oversight for access to the sensitive group.