Keep your workspace's member list in lockstep with your directory, so joiners and leavers are handled automatically.
Who this is for
The Owners of the account that holds the workspace, when the account is on the Enterprise plan.
Before you start
Set up and test single sign-on first. SCIM provisions the accounts that SSO then lets in; doing it the other way round provisions people who cannot sign in.
Steps
Open Single sign-on & SCIM for your workspace.
Select Enable SCIM.
Copy the SCIM base URL.
Copy the token from Copy your SCIM token; it is shown once.
Paste both into your identity provider's provisioning configuration.
Assign the directory groups or users who should have access.
Optional, to give a directory group a role: under Directory groups to roles, select Add mapping.
Fill in the Group ID, the Group name, or both. The group ID is your provider's stable identifier and survives a rename in your directory. If you give both, the ID is the one we match on, and it is also the id your provider sees for that group when it reads the group list back. A mapping keyed on the name alone works the same way, with the name as that id.
Choose the Role that group's members should get: Admin, Developer, Reviewer, Translator or one of your custom roles. Then select Create mapping.
What happens next
Your identity provider creates, updates and deactivates members in the workspace as your directory changes. Somebody removed from the directory loses access without anyone in transglot doing anything, with one exception. An Owner of the account that holds the workspace keeps access through the account: removing them in your directory ends only the workspace membership the directory gave them, the account's Owners get an email saying so, and they keep full control until an Owner of the account removes them on the account's Owners & billing members page. The page says it the same way: deactivating a user revokes their access, except an Owner of the account, "who keeps access through the account until you remove them from it."
Without a mapping, a group or role attribute named after a built-in role (admin, developer, reviewer or translator) provisions that role, and everyone else arrives as a translator. With a mapping, everybody your directory puts in that group holds the role you chose, from the next sync onward.
Before you rely on that:
A group you mapped is applied exactly as you set it.
A group you have not mapped is treated as untrusted directory data. In the page's words, it is honored up to Admin and normally lands on translator, so a mis-sync in your directory can never hand out more than an admin holds. A group called "owner" is an unknown name like any other and provisions translators.
No sync, mapped or not, makes anyone an Owner of the account. The account's Owners are set on the account's Owners & billing members page.
Map every group you want kept in sync. An unmapped group is applied once, when your provider first pushes it, and then it is not a group we hold: it does not appear in the group list your provider reads back, and your provider's next update to it fails with "Group not found". Mapped groups are the ones that stay in step.
Removing a mapping does not change anyone's current role. It changes what the next sync of that group does.
Rotate token issues a new one and invalidates the old. Do that if the token might have been exposed, and update your identity provider immediately, because provisioning stops until you do.
Disable SCIM stops provisioning without removing anyone who is already there.
If it doesn't work
If the token was not copied, rotate it and copy the new one. It cannot be recovered.
If provisioning fails, check the base URL is exactly as shown, including the version segment.
If everyone lands as a translator, that group has no mapping, or the mapping's group ID does not match the one your provider sends. Try mapping on the group name instead.
If your provider reports "Group not found" for a group it synced before, that group has no mapping. Add one, keyed on the group ID your provider sends, and the sync can address it again.
If a mapping will not save, another mapping already claims that group ID or group name. Names are compared without regard to upper and lower case, so "Engineering-Leads" and "engineering-leads" count as the same name. Edit the existing mapping instead of adding a second.
A mapping also will not save if the group name you gave is admin, developer, reviewer or translator, in any capitalisation, or if the group ID is one of those four exactly. The form says the name "is the name of a built-in role, which is already its own group here. Use your directory group's own ID or name instead." The mapping would add nothing: a directory group called "developer" already provisions developers without one. A group named "owner" maps like any other directory group, to any role on the list.
Related
Set up single sign-on
The member list