Module 11 — Running the Workspace · Lesson 11.4
Directory Sync and Domain Auto-Join
SCIM provisioning, tokens and the provisioning log — and the asymmetry of auto-join
~11 min
What you'll learn
- Connect a SCIM provider and copy the base URL into your identity provider
- Mint, rotate and protect a SCIM bearer token
- Read the provisioning log and trigger a resync
- Decide about domain auto-join with the deprovisioning asymmetry in mind
Above about twenty people, managing membership by hand stops working: joiners get added late, leavers get removed never, and nobody can say with confidence who has access. Directory sync fixes that by making your identity provider the source of truth. Auto-join solves a different, smaller problem and solves only half of it.
SCIM provisioning
Settings → Directory sync. Add a SCIM provider — Okta, Azure AD / Entra, OneLogin, or any generic SCIM client — and copy the SCIM base URL into your identity provider's configuration.
Mint a bearer token here and give it to the provider. Tokens are rotatable, which matters: treat rotation as a scheduled task rather than an emergency procedure.
Once configured, the provider pushes users in and — the important half — deprovisions them when they are removed upstream. Seat limits are enforced, so provisioning cannot silently exceed what you are paying for, and welcome emails go out to new users.
There is a resync you can trigger manually, and a provisioning log that records what happened. Read the log after the initial configuration rather than assuming success; a misconfigured attribute mapping shows up there rather than as an error in your identity provider.
Why deprovisioning is the point
Provisioning is a convenience. Deprovisioning is a control.
The risk in any workspace is not that a new joiner waits a day for access. It is that a leaver keeps it for a year, because removing access is a task with no deadline and no complainant.
SCIM removes that entirely: the moment someone is deactivated in your identity provider, they are deactivated here. No human has to remember, which is the only reliable way to make it happen.
That is the argument for connecting it even at a size where manual invites still feel manageable.
Domain auto-join, and its asymmetry
The other half of the page: verify an email domain and turn on auto-join. Anyone signing up with a matching address lands in the workspace automatically.
This is genuinely useful at a company where the statement 'everyone with this domain should see this workspace' is true.
And here is the asymmetry that has to be understood before enabling it: auto-join ADDS people, and nothing removes them later. There is no corresponding automatic removal when someone leaves the company or the domain. Every person who ever signs up with a matching address is a member until a human deactivates them.
So it is an access-control decision, not a convenience toggle. Turn it on deliberately, on a domain you actually control, and only where the statement above is genuinely true. If you want automatic membership AND automatic removal, that is SCIM, not this.
The combination that works
At a company with an identity provider: SCIM for provisioning and deprovisioning, auto-join off. The identity provider is the single source of truth and there is no second path in.
At a company without one: manual invites with an invite policy and an approval queue, auto-join off unless your domain is tightly controlled.
At a small, single-domain company where everyone should be in: auto-join on is reasonable, with a quarterly membership review as the compensating control for the missing deprovisioning.
What does not work is auto-join on plus nobody reviewing. That is the configuration where a workspace accumulates former employees indefinitely.
Set up provisioning
- 1
Add a SCIM provider and copy the base URL
Settings → Directory sync. The base URL goes into your identity provider's configuration.
- 2
Mint a token and schedule its rotation
Tokens are rotatable. Make rotation a scheduled task rather than an incident response.
- 3
Read the provisioning log after configuring
A misconfigured attribute mapping shows up here rather than as an error upstream.
- 4
Decide auto-join with the asymmetry in mind
It adds and never removes. If you want automatic membership AND removal, that is SCIM.
What to watch
- Deprovisioning latency
- Time between someone leaving the company and losing workspace access.
- Healthy signal: Immediate with SCIM. Without it, this is a number nobody measures and everybody would be uncomfortable knowing.
- Members not in the directory
- Workspace members with no corresponding active identity-provider record.
- Healthy signal: Zero where SCIM is connected. Anything else is a path in that bypasses your source of truth.
- Auto-join growth
- New members arriving via domain auto-join per month.
- Healthy signal: Matching your actual hiring. Anything more means the domain is looser than you thought.
Key takeaways
- ·SCIM connects an identity provider that provisions AND deprovisions; deprovisioning is the real value.
- ·Copy the SCIM base URL into your provider, mint a rotatable token, and read the provisioning log.
- ·Domain auto-join only ever ADDS members — nothing removes them when they leave.
- ·With an identity provider: SCIM on, auto-join off. Without: invites with a policy.
- ·Auto-join without a periodic membership review is how a workspace accumulates former employees.
Next: getting things back — trash, undo, and the audit log.