Sync user groups from your identity provider (private instances)
This article applies to private instances of Thunk.AI. Your identity provider administrator and Thunk.AI support set it up together.
On a private instance, Thunk.AI can take its users and groups straight from your identity provider — Microsoft Entra ID (formerly Azure AD), Okta, or any provider that supports SCIM 2.0. Once groups are synced you can:
provision and deprovision users automatically, as people join and leave;
restrict sign-in to members of chosen groups;
grant access to a group instead of to one person at a time, so access follows your directory.
For how organizations, roles, and environments work, see Orgs, Roles, and Environments.
Two ways to sync
SCIM 2.0 provisioning | Sign-in group sync | |
How it works | Your identity provider pushes users and groups to Thunk.AI on its own schedule | Thunk.AI reads a user's current groups from Microsoft Entra ID each time they sign in |
Providers | Microsoft Entra ID, Okta, any SCIM 2.0 provider | Microsoft Entra ID only |
How quickly changes arrive | On the provider's schedule — about every 40 minutes for Entra ID by default | Within a minute of the user signing in |
SCIM is the foundation and the source of record: it creates users, updates groups, and removes people who leave. Sign-in group sync is an addition for Entra ID customers — a user added to a group this morning gets the matching access the next time they sign in, rather than at the next provisioning cycle. If sign-in sync is unavailable for any reason, Thunk.AI keeps using the SCIM data.
Both follow nested groups: a user in a group that is itself a member of another group counts as a member of both.
Choose which groups to sync
Large directories have thousands of groups, and most have nothing to do with Thunk.AI. Pick a naming convention — for example, every group that controls Thunk.AI access contains thunk — and give it to Thunk.AI support. Only groups whose names contain that text (ignoring case) are synced. You can give more than one pattern.
Set up SCIM provisioning
Thunk.AI support gives you two values for your instance: the SCIM URL (it ends in /scim/v2) and a secret token.
Microsoft Entra ID
In the Entra admin center, go to Enterprise apps → New application → Create your own application, name it (for example Thunk SCIM Provisioning), and choose the non-gallery option.
Open the app's Provisioning page and set Provisioning Mode to Automatic.
Under Admin Credentials, enter the SCIM URL as the Tenant URL and the secret token as the Secret Token. Choose Test Connection, then Save.
Under Settings → Scope, choose which users and groups to provision.
Set Provisioning Status to On and save. The first sync starts.
Okta and other providers
Create a SCIM 2.0 provisioning app, point it at the SCIM URL, and use the secret token as a bearer token. Turn on pushing users and groups.
To check it worked without waiting for the schedule, use your provider's on-demand action — Provision on demand in Entra ID, Push Now in Okta — for one user.
When your identity provider deletes a user through SCIM, their Thunk.AI account is deactivated. Removing someone from a synced group removes the access that group gave them. Thunk.AI does not accept SCIM updates to an individual user's attributes, so deprovision by deleting rather than by marking a user inactive — ask Thunk.AI support if your provider only does the latter.
Set up sign-in group sync (Entra ID)
In the Entra admin center, go to App registrations → New registration. Name it (for example Thunk Group Sync) and allow accounts in your organizational directory only. No redirect URI is needed.
Note the Application (client) ID and Directory (tenant) ID, and create a client secret under Certificates & secrets.
Under API permissions, add these Microsoft Graph application permissions, then Grant admin consent:
User.Read.AllGroupMember.Read.AllGroup.Read.All
Send the client ID, tenant ID, and secret to Thunk.AI support through a secure channel. Support turns the feature on for your instance.
Restrict sign-in to groups
You can limit who can sign in to your instance to members of one or more groups. A person must belong to at least one of them; anyone else is turned away with Access restricted to authorized groups - contact your IT admin, even with a valid sign-in.
This works with the groups your identity provider includes in the sign-in token. Configure your provider to include a groups claim, then give Thunk.AI support the groups to allow — by group ID (preferred, since IDs never change) or by name, in the same form they appear in the token.
Grant access to groups
When group assignment is turned on for your instance, the places where you add people also accept synced groups:
organization members and admins;
the members of a resource environment;
a thunk's Users and Roles.
Start typing and the picker offers both people and groups. A group's members get the access through the group, and it follows your directory: someone added to or removed from the group in your identity provider gains or loses the access on the next sync. An org admin role held through a group is recognized in the same way as one granted directly.
Any signed-in user of your instance can see and pick synced groups, whether or not they belong to them, so that administrators can assign groups they manage but are not in.
To turn on group assignment for your instance, contact Thunk.AI support.