Set up automatic provisioning (SCIM)

Part of Single sign-on (SSO) for your workspace.

Automatic provisioning lets your identity provider manage your workspace's members for you. When someone joins your company, your directory adds them to Tinct; when their name or address changes, Tinct follows; when they leave, your directory deactivates them and their access to Tinct ends within seconds. Tinct speaks SCIM 2.0, the standard Okta, Microsoft Entra ID and most other identity providers use for this.

What you need

• You must be an admin of the workspace, on the Enterprise plan.
• At least one verified email domain. See Verify your email domain.
• Single sign-on enabled: your connection tested and switched on. See Single sign-on (SSO) for your workspace.
• An identity provider that can provision users over SCIM 2.0, and the rights to set it up there.

Until the last two hold, the Provisioning (SCIM) card on Settings → Security lists what is missing, with a link to the card where you fix it.

Who your directory manages

Your directory sees and manages only the people whose address is on one of your verified domains. Members and guests on other domains (an agency, a contractor, a client) are invisible to it: you keep managing them in Tinct, as before.

When your directory sends someone:

• A member of your workspace already is taken over by the directory. They keep their role.
• Someone with a Tinct account who is not a member joins your workspace with the role of new members set on the Provisioning card of single sign-on (Editor or Viewer).
• Someone without an account gets one, and joins the same way. They sign in through your identity provider; no invitation email is sent.
• Someone you invited has their invitation accepted for them.

On Settings → Members, the people your directory manages carry a Directory badge.

💡 An account whose address was never confirmed loses its password when your directory takes it over, and signs in through your identity provider from then on. This stops anyone who opened an account with your company's address, before its owner did, from keeping a way in.

What is synchronised

• Email address, sent as the SCIM userName. It must be the person's work address, on one of your verified domains. A change of address is applied at once, without a confirmation email, as long as the new address is on a verified domain too and not used by another account.
• First and last name.
• Active or not: see Deactivating someone.
• Group membership, if you push groups, to set roles from your directory. See Manage roles with directory groups.

Nothing else your directory sends is stored.

1. Generate a token

1. Go to Settings → Security, to the Provisioning (SCIM) card.
2. Copy the Base URL: your identity provider sends its requests there.
3. Under Tokens, click Generate token. Copy the token from Your new SCIM token and keep it for step 2. This token is shown only once: if you lose it, generate another one.

You can generate the token and set up your identity provider before switching provisioning on: its requests are refused until you do.

2. Set up your identity provider

Follow Okta or Microsoft Entra ID below. For another provider, give it the base URL and the token as a bearer token (an Authorization: Bearer … header), use the work email as the userName, and let it create, update and deactivate users.

3. Switch provisioning on

1. On the Provisioning (SCIM) card, turn on the switch.
2. In Switch on SCIM provisioning?, click Switch on.

The card then shows when your identity provider last called Tinct. Once it has, assign people to the Tinct application in your identity provider, or start its provisioning, and check that they appear on Settings → Members with the Directory badge.

Rotating a token

A workspace can hold two tokens at a time, so that you can replace one without interruption:

1. Click Generate token and copy the new token.
2. Put it in your identity provider in place of the old one, and check that provisioning still works (the Last used column of the new token fills in).
3. Click Revoke on the old token. Any request made with it is refused from then on; this cannot be undone.

A token your identity provider has not used for 90 days is marked Unused for 90 days, and your workspace admins get an email about it. Revoke it if nothing uses it any more.

Deactivating someone

When your directory deactivates a person (unassigning them from the Tinct application in Entra or from the provisioning application in Okta, or deactivating their account, does it), Tinct, within seconds:

• suspends their membership of your workspace. On Settings → Members they read Deactivated by directory;
• ends every session and token they hold: they are signed out of Tinct, and AI assistants connected through MCP lose access;
• blocks their account from signing in to Tinct by any method: password, Google, Microsoft or LinkedIn, and single sign-on.

The block covers the whole Tinct account, because the address belongs to a domain your company has proven it owns. Memberships the person holds in other workspaces are not changed, but they cannot reach them while the block holds.

When your directory re-activates them, the block is lifted and they come back with the role of new members, or the role their directory groups map to. A role they held before, admin included, is not given back by itself: an admin gives it again.

When your directory deletes them, they are deactivated as above and their membership is removed. Their account stays blocked from signing in until your directory provisions them again.

💡 Your directory cannot deactivate, delete or demote your workspace's last admin: the request is refused, and your identity provider shows an error for that person. Make another member an admin first.

While provisioning is on

• Members your directory manages are managed there. On Settings → Members, Suspend access, Restore access and Remove are unavailable for them, with the reason shown. Your directory would undo any such change at its next synchronisation.
• Their role stays yours to change in Tinct, unless one of their groups maps to a role. See Manage roles with directory groups.
• Turn off "Create accounts at first sign-in" on the Provisioning card of single sign-on. With it off, only people your directory provisioned can come in through your identity provider; someone it has not provisioned is refused at sign-in. Your directory becomes the one list of who has access to Tinct.

Switching provisioning off

Turn off the switch on the Provisioning (SCIM) card, then click Switch off. Nobody is deprovisioned: members keep their accounts and their access, and you manage them in Tinct again. Your identity provider's requests are refused, and its tokens stop working, until provisioning is switched on again.

Provisioning also stops answering while single sign-on is off, or when your last verified domain is removed. Nobody is deprovisioned then either.

Okta

These steps are those of the Okta Admin Console (Okta Identity Engine) as of 2026. In Okta, provisioning is set up in a second application, used for provisioning only, next to the one you set up for single sign-on (see Set up SSO with Okta). Keep signing in through the first one.

💡 Why a second application? Okta cannot provision from an OpenID Connect application. A SAML application can, but it sends the same Application username as the sign-in identifier and as the SCIM username: single sign-on needs Okta's own identifier there, which never changes, and provisioning needs the work email. With the email in both, someone whose address changes in Okta can no longer sign in to Tinct. Two applications keep each one right.

Create the provisioning application

1. In the Okta Admin Console, open Applications → Applications, click Create App Integration, choose SAML 2.0, and click Next.
2. Under General Settings, name it (for example Tinct provisioning), tick Do not display application icon to users, and click Next. Nobody signs in through this application.
3. Under Configure SAML:
   • Single sign-on URL and Audience URI (SP Entity ID): the Base URL from Tinct. Okta requires a value; this application never sends a sign-in.
   • Application username: Email, and Update application username on: Create and update. Tinct takes the username as the person's work address.

Click Next, choose This is an internal app that we have created, and click Finish.

1. On the General tab, in App Settings, click Edit, set Provisioning to SCIM, and click Save. A Provisioning tab appears.

Connect it to Tinct

1. On the Provisioning tab, under Integration, click Edit and fill in:
   • SCIM connector base URL: the Base URL from Tinct
   • Unique identifier field for users: userName
   • Supported provisioning actions: Push New Users, Push Profile Updates and, to set roles from groups, Push Groups
   • Authentication Mode: HTTP Header, and paste the token under Authorization (Bearer)
2. Click Test Connector Configuration. Okta lists what it found; close the window and click Save.
3. Still on Provisioning, under To App, click Edit, enable Create Users, Update User Attributes and Deactivate Users, and click Save.

Assign people to both applications

On the Assignments tab of each application, assign the people who use Tinct: the provisioning application creates them in Tinct, right away, and the sign-in application lets them sign in. The simplest way to keep the two in step is to assign one Okta group to both.

Someone assigned to the provisioning application only is created in Tinct, but Okta refuses their sign-in. Someone assigned to the sign-in application only can sign in, but your directory does not manage them.

Unassigning someone from the provisioning application, or deactivating them in Okta, deactivates them in Tinct, and Tinct then refuses their sign-in whatever the sign-in application allows.

Microsoft Entra ID

These steps are those of the Microsoft Entra admin center as of 2026. Provisioning is set up on the enterprise application you use for single sign-on, if you set it up with SAML (see Set up SSO with Microsoft Entra ID).

💡 Signing in with OpenID Connect? Entra ID cannot provision from an application created under App registrations: its Provisioning page says automatic provisioning is not supported. Create a second application for provisioning only: Enterprise applications → New application → Create your own application, choose Integrate any other application you don't find in the gallery (Non-gallery), and follow the steps below in it. Assign the same people to both applications: the first one lets them sign in, the second one provisions them.

1. In the Microsoft Entra admin center, go to Identity → Applications → Enterprise applications and open your Tinct application.
2. Open Provisioning, then click Connect your application (or New configuration).
3. Under Admin credentials:
   • Select authentication method: Bearer authentication
   • Tenant URL: the Base URL from Tinct, followed by ?aadOptscim062020. This flag makes Entra follow the SCIM standard in the requests it sends; Tinct accepts both forms, but Microsoft recommends it for new applications.
   • Secret token: the token from Tinct.
4. Click Test connection, then create the configuration. Entra opens its Provisioning page, with the Provisioning Mode set to Automatic.
5. On that page, under Mappings, open Provision Microsoft Entra ID Users and check the source of userName. By default it is the userPrincipalName; Tinct refuses a userName that is not the person's work email. If your user principal names differ from the email addresses, click Edit on the userName row, take it from mail instead, and Save. Keep emails[type eq "work"].value from mail.
6. Under Settings, check that Scope is Sync only assigned users and groups.
7. Under Users and groups of the application, assign the people or groups that use Tinct.
8. Back on the Provisioning page, set Provisioning Status to On and Save.

Entra provisions in cycles, about every 40 minutes; the first one can take longer. To try one person at once, use Provision on demand, in the menu of the provisioning pages: it shows each step and, when Tinct refuses someone, Tinct's reason. Unassigning someone, blocking their sign-in in Entra or deleting them deactivates them in Tinct; Entra deletes them in Tinct when it deletes them for good.

Troubleshooting

My identity provider's test says 403.

Provisioning is off, single sign-on is off, or no domain is verified. The Provisioning (SCIM) card says which.

My identity provider says 401.

The token is wrong, revoked, or belongs to another workspace. Generate a new one and paste it again. If requests with a bad token keep arriving, your workspace admins get an email about it.

Someone is refused with "userName" or "invalidValue".

Their address is not on one of your verified domains, or the username your identity provider sends is not their work email. See step 3 of Create the provisioning application for Okta, and step 5 for Entra. Entra shows Tinct's reason in Provision on demand and in its provisioning logs, for example userName and the work e-mail must be the same address.

Someone is not provisioned, and is not in the error log either.

Check that they are assigned to the Tinct application, and that their address is on a verified domain: people on other domains are ignored.

A deactivation is refused.

That person is your workspace's last admin. Make another member an admin, then retry from your identity provider.

For anything else, write to support@tinct.ai.