Group-based permissions
Glean supports assigning roles and feature access to identity provider (IdP) groups. Instead of configuring individual user roles, you can map IdP groups to Glean roles to enable automatic permission inheritance based on group membership.
Group-based permissions are separate from Agent sharing. A group that is available for role mapping is not automatically available in the Agent sharing picker. To share an agent with a group, see Share agents with identity provider groups.
Group-based permissions allow you to:
- Assign roles to IdP groups: Manage Glean roles collectively rather than per individual user.
- Manage permissions at scale: Leverage existing identity provider groups.
- Control feature access: Use groups in feature greenlists, such as access to Glean and connector test groups.
- Automate inheritance: Ensure users automatically receive or lose permissions as their IdP group memberships change.
Group-based permissions control Glean roles and feature access only. This feature does not change or override connector permissions. Glean continues to honor all source system ACLs exactly as configured in your connectors.
Supported identity providers
Glean supports group-based permissions for the following identity providers:
| Identity Provider | Group Support | Notes |
|---|---|---|
| Azure AD (Microsoft 365) | ✓ | Groups synced via the O365 connector |
| Google Groups (Google Workspace) | ✓ | Groups synced via the Google Workspace connector |
| Okta | ✓ | Groups synced via the Okta connector. Requires the okta.groups.read scope. |
Glean only reads group membership information from your identity provider. It does not sync, modify, or enforce IdP permission rules.
Group-to-Role Mapping
Groups as principals
In Glean's role-based access control (RBAC) model, groups are treated as principals alongside individual users. This means a group can be assigned:
- One primary role (Member, Setup Admin, Admin, or Super Admin)
- Multiple secondary roles (such as Agent Creator, Skill Creator, Answers Moderator, Insights Moderator, or Sensitive Content Moderator)
Effective permission calculation
When a user belongs to one or more groups with assigned roles, Glean calculates effective permissions by merging:
- Roles assigned directly to the user
- Roles inherited from all groups the user belongs to
Glean applies the following rules during the merge:
- Primary role: The highest-precedence role takes effect. Precedence follows this order: Super Admin → Admin → Setup Admin → Member.
- Secondary roles: All secondary roles from the user's direct assignments and group memberships are combined (union).
Prerequisites
Complete the following prerequisites:
- Have the Admin or Super Admin role to configure group-based permissions. See Administrator Roles.
- Connect a supported identity provider to Glean, so that Glean can read group membership. See Supported identity providers.
- Configure the identity connector that supplies the groups and memberships, then complete an identity crawl:
- Microsoft 365 setup
- Google Workspace setup
- Okta setup. Grant the
okta.groups.readscope so Glean can read Okta groups and memberships.
Make IdP groups available in Glean
To use IdP groups in model access restrictions or other Glean group selectors, select your identity provider in User group permissions and save. You don't need to add a group-to-role mapping.
To configure the group datasource, follow the steps in Configure Group-to-Role mappings and skip Add group mappings.
Configure Group-to-Role mappings
Admins can map IdP groups to Glean roles from the User Roles page in the Admin console. The same steps configure the group datasource that other Glean features use.
Steps to Configure
Access User Group Permissions
Click the Default Member permissions button, then navigate to the User group permissions section.
Select Identity Provider
Choose the identity provider that contains your groups (for example, Microsoft 365, Google Workspace, or Okta).
This step is required, even if you don't add any group mappings.
Add Group Mappings (optional)
Skip this step unless you want group members to inherit Glean roles.
Click Add mapping to create a new group-to-role mapping:
- Search and select a group by name or email.
- Assign a primary role for the group.
- Optionally assign one or more secondary roles.
- Repeat for additional groups as needed.
Save Changes
Click Save changes. This step is required. Saving configures the group datasource and applies any group mappings you added.
Limits and sync behavior
- You can assign roles to a maximum of 1,000 groups.
- Glean automatically syncs group membership changes from your IdP. The synchronization frequency depends on your integration type:
- SAML/SCIM integrations: Changes sync in near real-time.
- OIDC integrations: Changes may take up to three hours to sync.
- An on-demand sync control is available to refresh group membership immediately.
Use groups for feature access
For Okta, group-based permissions currently apply to group-to-role mappings.
Group-based permissions integrate with Glean's greenlist-style provisioning for features such as:
- Glean access: Grant Glean access to entire groups instead of adding users individually.
- Feature rollouts: Use groups to control access to beta features or phased rollouts.
- Connector test groups: Include groups when configuring which users can see results from a connector during testing.
When configuring these features, you can now select groups as principals in addition to individual users.
Privacy and Security
Group information visibility
Only Admins and Super Admins can view group names, descriptions, and membership information within the Admin console. Regular users cannot view their group memberships or identify how the system derives their permissions.
For organizations with sensitive group structures (such as executive or M&A-related groups), contact Glean support to discuss options for limiting group name visibility.
Manage group-derived roles
Glean treats roles inherited through group membership as read-only. To modify these inherited roles, you must perform one of the following:
- Add or remove the user from the relevant group in your identity provider.
- Modify the role mapping for the group in Glean Admin console.
You cannot directly remove a group-derived role from an individual user in the Glean Admin console.
Safety rails
The following guardrails apply to group-based permissions:
- Admins cannot remove the last user or group from any role.
- Admins cannot downgrade or remove Super Admin permissions from users or groups.
- Only Super Admins can assign the Super Admin role to groups.
Limitations
The following limitations apply to group-based permissions:
| Limitation | Details |
|---|---|
| Okta groups | Available for group-based role mappings after the initial Okta group crawl completes. |
| Group membership latency | OIDC-based integrations may have up to 3 hours of sync delay for membership changes. |
| Custom roles | Group-based permissions work with Glean's existing role structure. Custom role definitions are not currently supported. |
| Feature flag | Group-based permissions are controlled by a feature flag. If the feature is disabled, group-derived roles are ignored and only direct user role assignments apply. |
Examples
Example 1: IT administrators group
Map your IT Admins group to the Admin role so that all IT team members automatically receive Glean Admin permissions:
| Group | Primary Role | Secondary Roles |
|---|---|---|
| IT-Admins@company.com | Admin | — |
Example 2: Glean Pilot Group
Grant Glean access to a pilot group of early adopters:
| Group | Primary Role | Secondary Roles |
|---|---|---|
| Glean-Pilot@company.com | Member | — |
Then configure Glean access to include this group in the test group settings.
Example 3: Content Moderators
Assign content moderation permissions to your knowledge management team:
| Group | Primary Role | Secondary Roles |
|---|---|---|
| Knowledge-Team@company.com | Member | Answers Moderator, Collections Moderator |