Automatic provisioning (SCIM)
Your directory already knows who works at your company. Provisioning lets it keep your Writizzy team in step: assign someone to the application and they get access, deactivate them and they lose it the same minute.
This works through SCIM 2.0, so it is driven from your directory's own provisioning settings: Okta, Microsoft Entra ID, Google Workspace, JumpCloud, and any other that speaks the standard. A script of your own calling the same endpoints works just as well.
Provisioning requires the Team plan.
Set up single sign-on first
Provisioning does not work on its own. It relies on the connection to your directory and on the email domain you have proven you own, and both come from single sign-on. Until a domain is verified, a provisioning token is refused.
Setting it up
Under Settings → Team → Single sign-on, section Provisioning.
1. Choose the role people arrive with
Everyone your directory sends gets the same one: it knows who works at your company, not what they do on your blog. Change it per person afterwards from the team screen.
People land on the blog you are setting this up on, and only that one. If you have other blogs, this directory has no say over them.
2. Generate the token
Click Generate token. It is shown once and never again. Copy it before leaving the screen.
If you lose it, generate another one. That replaces the old one, which stops working immediately, so your directory has to be given the new one.
3. Point your directory at us
In your directory, enable provisioning on the Writizzy application and fill in two things:
| Field | Value |
|---|---|
| Base URL, or tenant URL | The provisioning URL shown on the Writizzy screen |
| Token, or secret token | The token you just generated, as a bearer token |
Your directory will test the connection. Then enable the operations you want: create users, update attributes, deactivate users.
4. Import what already exists
Your directory reads the team as it stands. People who joined by invitation before you set this up are picked up as they are, not created a second time, provided their address is in a verified domain.
From then on, your directory is the one keeping the list up to date.
What happens, and when
| In your directory | On your blog |
|---|---|
| Someone is assigned to the application | They get access straight away, with the role you chose. No invitation to accept |
| Someone's name changes | Their name changes here |
| Someone's address changes | Their address changes here, as long as the new one is in a verified domain and nobody else already uses it |
| Someone is deactivated or removed | They lose their place on this blog, and their open sessions end immediately |
| Someone is reactivated | Your directory creates them again, and they get their place back with the role set on the connection, not the one they had before |
| Someone is removed by hand from the Writizzy team screen | Your directory sees them as deactivated on its next read |
Nothing is ever deleted. A departure removes the seat, never the person: their account, their published articles and the newsletters they read are untouched. Their name stays on what they wrote, which is what you want on a blog.
A departure is final as far as your directory is concerned. We forget the link between it and that person, so the identifier it kept stops answering. That is deliberate: a directory that can still name someone can still act on them, months after they left. If they come back, your directory simply creates them again.
What your directory cannot do
Four limits, and none of them can be lifted by what your directory sends:
- The blog's owner is out of reach. Losing them would leave the blog with nobody, and their address is often not in the directory to begin with. Change the owner from Settings → Team → Transfer ownership.
- Your other blogs are out of reach. A directory governs the blog it was set up on. Arrivals land there, departures only take that seat.
- Addresses outside your verified domains are refused. Same barrier as for signing in, and it applies to the address someone holds today, not only to the one your directory sends. If a former colleague has moved their account to a private address, your directory can no longer touch it.
- An account we have closed stays closed. A directory reactivating someone does not reopen it.
Groups are not mapped
Roles come from the connection, the same for everyone, and not from your directory's groups. Mapping groups onto roles would mean guessing how each company names its groups, and it would be wrong for most.
The groups endpoint answers, so that your directory's setup wizard does not stop on it, but it returns nothing. Assign roles on the Writizzy side, from Settings → Team.
Good to know
The token is the whole of your directory's identity. Treat it like a password. Only its fingerprint is stored here, so we could not show it to you again even if you asked.
A downgrade below the Team plan stops provisioning on the next call, without your having to revoke anything. Existing members keep their accounts.
Removing the single sign-on connection removes provisioning with it, token included. The activity record stays: it belongs to the blog, not to the directory.
Every arrival and departure is recorded, under Settings → Team → Single sign-on. See the activity record.