Dynamic approvers
Resolve the appropriate approver from an Okta user or group instead of embedding a fixed email address in every workflow.
“Who should approve the Atlas vendor renewal?”
Roster for Okta
Turn Okta users and groups into runtime routing context for AI agents and workflows.
Roster connects to your Okta organization to resolve who should approve, own, review, receive, or handle work. Use current Okta users and groups as the organizational foundation for participant resolution—without hard-coding names into prompts, workflows, or application logic.
Last verified 07/13/2026
Your directory knows who people are. Roster resolves who should act.
Okta provides the users, groups, profiles, and membership data your organization already maintains.
But an agent or workflow rarely asks only:
“Which users belong to this group?”
It asks:
“Who should approve this request?”
“Who owns this customer escalation?”
“Who is responsible for the security review?”
“Who should act while the normal owner is unavailable?”
Roster turns selected Okta users and groups into participants with project, role, metadata, and delegation context—then exposes that context to AI agents, automation systems, CI pipelines, and internal applications.
How Roster connects to Okta
Roster's native Okta connector reads users, groups, and direct group membership through the Okta Core API.
When an administrator searches for an Okta user or group from Roster, the connector queries Okta live.
After the administrator associates a selected record with a Roster participant, Roster materializes that record for participant resolution. For a selected group, Roster also stores the direct membership relationships needed to resolve its members.
Roster does not full-sync every user, group, and membership in your Okta organization. Its worker refreshes the selected records and membership relationships used by Roster on a configured schedule.
What you can resolve
Workflow owners
Map an Okta group to a Roster participant such as Vendor Security Reviewer, Regional Finance Owner, or Production Release Approver.
“Who owns the security review for the Atlas project?”
Active delegates
Apply time-bound Roster delegations when the normal participant is unavailable.
“Who can approve this while the procurement owner is away?”
Escalation contacts
Resolve the user or group responsible for a particular project, customer, region, process, or risk level.
“Who should receive this enterprise customer escalation?”
Agent-to-human handoffs
Give AI agents a reliable way to select the right person or team when a workflow requires human judgment.
“Which human reviewer should this agent ask before executing the action?”
From an Okta group to a workflow participant
An Okta group identifies a set of users. A Roster participant describes the business responsibility those users can fulfil.
The same Okta group can support different workflow responsibilities in different Roster projects without changing the source directory.
Roster participants can also carry business metadata such as: Region, Department, Approval threshold, Review type, Product, Customer segment, Escalation level.
That gives the resolver more context than a directory lookup alone.
Use Okta context from every Roster surface
Once Okta records have been associated with Roster participants, the same organizational context is available across Roster's integration surfaces.
MCP
Let Claude, ChatGPT, Codex, or another compatible MCP client ask open-ended routing questions.
REST API
Add participant resolution to internal applications, automation platforms, and custom agent runtimes.
CLI and CI
Resolve ownership or sign-off requirements from the terminal or a CI pipeline.
Roster platform
Let administrators and project owners browse Okta records, create participants, manage memberships, configure delegations, and review resolution activity.
What Roster reads from Okta
| Okta data | Used by Roster | Materialized in Roster |
|---|---|---|
| Stable user ID | Yes | For selected users and group members |
| User login | Yes | For selected records |
| User email | Yes | For selected records |
| Display name | Yes | For selected records |
| Stable group ID | Yes | For selected groups |
| Group name | Yes | For selected groups |
| Group email, when present | Yes | For selected groups |
| Direct group members | Yes | For selected groups |
| Passwords and authenticators | No | No |
| Applications and entitlements | No | No |
Roster normalizes the selected provider records into its own directory-user and directory-group representation while retaining their Okta source identifiers.
The connector currently uses these Okta Core API resource paths:
/api/v1/users
/api/v1/groups
/api/v1/groups/{id}/usersRoster's current connector is designed to read the user, group, and membership information needed for participant resolution. It does not use the connector to administer Okta users or groups.
Live lookup and materialized resolution
Roster uses two deliberate data-access modes.
Live provider browsing
An administrator can search Okta live while selecting users or groups from the Roster participant picker. This makes it possible to find records that have not previously been added to Roster.
Materialized runtime resolution
After a record has been selected, Roster stores the directory representation required for participant resolution. REST and MCP directory searches use this materialized Roster data rather than calling Okta live during every agent or workflow request. This provides a consistent runtime dataset across Roster's API, MCP, CLI, and platform surfaces.
Connection requirements
To configure the Okta directory connector, you need:
- 01Your Okta organization URL
- 02An Okta API token
- 03A secure environment variable or secret-manager reference
- 04An appropriate refresh schedule
- 05Stable Okta user and group identifiers
- 06Sufficient read access to the users, groups, and memberships selected for Roster
The current connector uses SSWS API-token authentication with the Okta Core API.
Use the least-privilege Okta administrator role that allows the connector to read the required users, groups, and membership information. Apply appropriate token ownership, rotation, expiration, and revocation controls.
Example secret reference:
env:OKTA_API_TOKENKeep the token outside application code and source control.
Your Okta directory is not your Roster login configuration
Roster supports two separate Okta integration paths.
Okta directory connector
Provides users, groups, and group membership for participant resolution.
Okta identity provider
Lets human team members sign in to the Roster platform through Okta using OIDC—or through an independently configured SAML application.
These integrations can be used independently or together. Configuring Okta login does not automatically make Okta directory records available to the resolver. Likewise, configuring the directory connector does not automatically enable Okta login.
Built for controlled enterprise deployment
Selective materialization
Roster refreshes the users, groups, and direct group memberships selected for participant resolution rather than importing the entire Okta directory.
External secret storage
The Okta API token can remain in the deployment environment or secret manager and be referenced by the Roster connector.
Scheduled refresh
Roster's worker updates selected directory records and cached membership relationships according to the configured refresh schedule.
Stable provenance
Materialized records retain their provider-specific source information and stable Okta identifiers.
Scoped Roster access
Agents, service accounts, and applications still require appropriate Roster credentials, scopes, and project access before they can read or resolve participant data.
Example: dynamically resolve a procurement approver
An automation receives a vendor-renewal request for the Atlas project. The workflow knows: the project, the vendor region, the contract value, the action that requires approval. It does not contain a fixed approver email.
Instead, it asks Roster:
“Who should approve the Atlas vendor renewal for Europe at this amount?”
Roster evaluates:
- the Atlas project
- the relevant procurement participant
- participant metadata
- the associated Okta user or group
- current materialized membership
- any applicable Roster delegation
The workflow receives the active participant and continues with its existing approval-delivery mechanism. Roster resolves who should receive the request. Your workflow engine remains responsible for sending, collecting, and enforcing the approval.
Common Okta and Roster use cases
- Resolve an approver from an Okta group
- Route AI-agent actions to a human reviewer
- Identify the owner of a project or process
- Resolve regional or departmental responsibility
- Apply temporary delegation during leave
- Route customer or operational escalations
- Determine release or deployment sign-off
- Replace static approver emails in workflows
- Give MCP clients access to organizational context
- Reuse the same participant logic across multiple applications