Dynamic workflow approvers
Resolve the correct approver from a current Workspace user or Google Group instead of embedding an email.
“Who should approve this marketing-data export?”
Roster for Google Workspace
Turn Google Workspace users and groups into organizational context for agents and workflows.
Roster connects to the Google Workspace Admin SDK Directory API to resolve who should approve, own, review, receive, or handle work. Use current Workspace users and Google Groups without hard-coding names or email addresses into every workflow.
Last verified 07/13/2026
Google Workspace manages your users and groups. Roster resolves responsibility.
Google Workspace can tell an application which users and groups exist.
Roster adds the workflow context needed to answer:
“Who is in this Google Group?”
It asks:
“Who should approve this request?”
“Which group owns this customer account?”
“Who should review this security exception?”
“Who is the active delegate for this responsibility?”
Selected Workspace users and groups can be associated with Roster participants representing project-specific responsibilities. Roster then evaluates the participant model, current materialized membership, metadata, and active delegations before returning who should act.
How Roster connects to Google Workspace
Roster reads users, groups, and direct group membership through the Admin SDK Directory API v1.
When an administrator searches from the Roster participant picker, the connector queries Workspace live.
After a record is selected, Roster materializes it for participant resolution. For selected groups, it also stores the direct membership relationships needed by the resolver.
MCP and REST directory searches use materialized Roster records rather than calling Google Workspace live for every request.
What you can resolve
Group-based responsibility
Associate Google Groups with participants representing project or process ownership.
“Which group handles privacy review?”
Project and process owners
Map an owner to each project workflow via participants.
“Who owns the Atlas customer onboarding workflow?”
Human reviewers for agent actions
Let agents resolve the appropriate reviewer before taking a sensitive action.
“Who should review this customer-data export?”
Delegated coverage
Apply time-bound Roster delegations without changing Workspace membership.
“Who is covering for the normal approver?”
From a Google Group to a Roster participant
The group supplies directory membership. The Roster participant supplies the business meaning and project context.
A single Google Group can back different responsibilities across different Roster projects without any change in Workspace.
Participants carry metadata such as: Region, Product, Approval threshold, Data class, Customer tier, Escalation level.
Use Workspace context from every Roster surface
Once Workspace records back Roster participants, the same organizational context is available everywhere.
MCP
Let an MCP-compatible AI client ask open-ended routing questions.
REST API
Add participant resolution to internal tools and custom agents.
CLI and CI
Resolve ownership from the terminal or a CI pipeline.
Roster platform
Browse Workspace users and Google Groups, associate them with participants, manage delegations.
What Roster reads from Google Workspace
| Workspace data | Used by Roster | Materialized in Roster |
|---|---|---|
| Stable Google user ID | Yes | For selected users |
| Primary email | Yes | For selected users |
| Full name | Yes | For selected users |
| Stable group ID | Yes | For selected groups |
| Group email | Yes | For selected groups |
| Group name | Yes | For selected groups |
| Group description | When available | For selected groups |
| Direct group members | Yes | For selected groups |
| Passwords and authentication factors | No | No |
| Gmail messages and Drive content | No | No |
Typical Directory API resources:
/users
/groups
/groups/{groupKey}/membersThe connector is intended for directory reads. It is not used to manage Workspace accounts or group membership.
Live browsing and materialized resolution
Roster uses two deliberate data-access modes.
Live provider browsing
Administrators can search Workspace live from the Roster participant picker when selecting users or groups.
Materialized runtime resolution
Runtime resolution uses Roster's materialized state, giving REST, MCP, CLI, and Resolve operations a consistent dataset independent of Google API availability.
Connection requirements
You need:
- 01A Google Workspace customer ID, commonly my_customer
- 02A delegated administrator in the Workspace domain
- 03A Google Cloud service account
- 04The service-account email
- 05A private key stored outside source control
- 06Domain-wide delegation
- 07Admin SDK Directory API enabled
- 08A refresh schedule
Roster's current default read scopes are:
https://www.googleapis.com/auth/admin.directory.group.readonly
https://www.googleapis.com/auth/admin.directory.user.readonlyStore the private key through an environment or secret-manager reference:
env:GOOGLE_WORKSPACE_PRIVATE_KEYThe connector uses service-account domain-wide delegation rather than an interactive end-user OAuth flow.
Workspace directory data and Google login are separate
The directory connector and human authentication are configured independently.
Workspace directory connector
Provides users, groups, and membership for participant resolution.
Google identity provider
A Google identity-provider configuration, when used, controls how human team members authenticate to Roster.
Connecting one does not automatically configure the other.
Example: route a privacy review
An agent is preparing to export customer information.
It asks:
“Who should review this customer-data export for the Atlas project?”
Roster evaluates:
- The Atlas project
- The Customer Data Privacy Reviewer participant
- Relevant labels and metadata
- The associated Workspace user or Google Group
- Current materialized membership
- Any active delegation
The agent receives the current reviewer and passes the work to the organization's existing review or approval channel.