Dynamic approvers
Select an approver from a current Entra user or group instead of storing a fixed email address in each workflow.
“Who should approve the Atlas production deployment?”
Roster for Microsoft Entra ID
Turn Entra users and groups into runtime routing context for AI agents and workflows.
Roster connects to Microsoft Entra ID through Microsoft Graph to resolve who should approve, own, review, receive, or handle work. Use the users and groups your organization already manages in Entra—without copying approver names into prompts, workflow definitions, or application code.
Last verified 07/13/2026
Entra identifies your workforce. Roster resolves who should act.
Microsoft Entra ID provides authoritative user identities, groups, and membership information.
But agents and workflows need answers to business questions:
“Which users belong to this group?”
It asks:
“Who should approve this request?”
“Which group owns this application?”
“Who should review this production change?”
“Who is covering while the normal owner is unavailable?”
Roster associates selected Entra users and groups with project-specific participants such as Production Release Approver, Vendor Security Reviewer, or Regional Finance Owner. It then resolves the active participant using directory membership, project context, labels, metadata, and Roster delegations.
How Roster connects to Microsoft Entra ID
Roster's native connector reads users, groups, and direct group membership through Microsoft Graph v1.0.
When an administrator searches for an Entra user or group in Roster, the connector queries Microsoft Graph live.
After the administrator associates a selected record with a participant, Roster materializes that directory record. For a selected group, Roster also stores the direct membership relationships required for participant resolution.
Runtime Resolve requests and directory searches through REST or MCP use Roster's materialized directory state rather than calling Microsoft Graph for every request.
What you can resolve
Application and service owners
Associate Entra groups with participants representing technical or business ownership.
“Who owns the customer identity service?”
Human reviewers for AI agents
Let an agent resolve the appropriate security, legal, finance, or operational reviewer before taking a sensitive action.
“Who should review this authentication change?”
Escalation contacts
Resolve the group or user responsible for a specific project, region, customer, application, or severity level.
“Who should receive this critical customer escalation?”
Delegated responsibility
Apply a time-bound Roster delegation when the normal owner is unavailable.
“Who is covering for the release approver this week?”
From an Entra group to a workflow participant
An Entra group identifies directory members. A Roster participant defines the responsibility those members can fulfil in a particular context.
The same Entra group can support different responsibilities across different Roster projects without changing the source directory.
Participants can also carry metadata such as: Region, Department, Product, Application, Approval threshold, Risk category, Customer segment, Escalation level.
Use Entra-backed context from every Roster surface
Once Entra records have been associated with Roster participants, the same organizational context is available across every Roster surface.
MCP
Let Claude, ChatGPT, Codex, or another compatible MCP client resolve organizational responsibility.
REST API
Add directory-backed participant resolution to internal tools, workflow engines, and custom agents.
CLI and CI
Resolve ownership and sign-off requirements from the terminal or deployment pipeline.
Roster platform
Let administrators browse Entra users and groups, associate them with participants, configure delegations, and review resolution history.
What Roster reads from Microsoft Entra ID
| Entra data | Used by Roster | Materialized in Roster |
|---|---|---|
| Stable object ID | Yes | For selected records |
| Display name | Yes | For selected records |
| User principal name | Yes | For selected users |
| Email address | When available | For selected users |
| Mail nickname | For lookup | As applicable |
| Group ID and name | Yes | For selected groups |
| Group email | When available | For selected groups |
| Direct group members | Yes | For selected groups |
| Passwords and authentication methods | No | No |
| Application secrets | No | No |
Typical Microsoft Graph resources used by the connector are:
/users
/groups
/groups/{id}/membersThe directory connector is read-oriented. It is not used to create, modify, or delete Entra users and groups.
Live lookup and materialized resolution
Roster uses two deliberate data-access modes.
Live provider browsing
Roster queries Microsoft Graph when an administrator searches for an Entra user or group from the participant picker.
Materialized runtime data
Once selected, the record is stored in Roster and associated with a participant. Selected group memberships are refreshed according to the configured schedule. REST, MCP, CLI, and Resolve operations use the same materialized state, giving every integration surface a consistent organizational context.
Connection requirements
To configure the connector, you need:
- 01A Microsoft Entra tenant
- 02An app registration
- 03A tenant ID
- 04A client ID
- 05A client secret stored outside source control
- 06Microsoft Graph application permissions
- 07Tenant administrator consent
- 08A refresh schedule
Roster's current client-secret implementation requires these Graph application permissions:
User.Read.All
Group.Read.All
GroupMember.Read.AllStore the secret in the runtime environment or your secret manager:
env:ENTRA_CLIENT_SECRETApply your organization's normal secret rotation, expiration, and revocation policies.
Entra directory data and Entra login are separate
Roster supports two distinct Microsoft Entra integration paths.
Entra directory connector
Provides users, groups, and membership information for participant resolution.
Entra identity provider
Lets human users sign in to Roster through Microsoft OIDC or an independently configured SAML enterprise application.
The two integrations can be used together or independently. Configuring Entra login does not automatically connect Entra directory data to participants. Configuring the directory connector does not automatically enable Entra login.
Example: resolve a production approver
A CI pipeline is preparing to deploy the Atlas application.
Instead of containing a fixed approver email, the pipeline asks:
“Who should approve the Atlas production deployment?”
Roster evaluates:
- The Atlas project
- The Production Release Approver participant
- Participant labels and metadata
- The associated Entra user or group
- Current materialized group membership
- Any active Roster delegation
The pipeline receives the active participant and can continue through its existing pull-request, deployment, ticketing, or approval system. Roster resolves who should act. It does not replace the system that sends or enforces the approval.