How should a B2B SaaS product design SSO and SCIM setup for enterprise admins?
A B2B SaaS team can design SSO and SCIM setup by fixing the order of steps, giving every state a recovery path, testing before enforcing, and deciding what removal does to accounts and content.
Illustrative situation: a SaaS company moves upmarket, and a prospect’s security team writes, “We require SAML single sign-on and SCIM provisioning before we sign.” Engineers have a working SAML endpoint and a token generated on a settings page. Nobody has designed what the customer’s IT admin does with them. The scene is invented, and it shows the gap this guide addresses: the protocol works, while the admin experience is left to a docs page.
Humbleteam, a digital product design agency, publishes this guide. It covers the screens an IT admin meets, from domain verification to deprovisioning, and it includes a setup-state table, a deprovisioning worksheet and an invented worked example. Vendor behavior below is described as of October 30, 2026 and can change.
Who uses these screens, and what do they need?
The main user is an IT admin who may never open your product again. They work in two consoles at once, their identity provider and yours. Others depend on the result: a security reviewer who wants proof that SSO is enforced, the business owner who wants the team unblocked, and every employee who meets a new sign-in page.
Give the admin values to copy and a way to test. Slack’s SAML setup asks for the endpoint URL, the issuer URL and an X.509 certificate, then offers a Test Configuration button. Linear accepts metadata as an XML URL or raw XML. Notion’s SAML page suggests trying a URL instead of an XML file when setup fails.
The person who bought the product often cannot finish setup alone. WorkOS, a vendor that sells this layer, offers an Admin Portal where IT contacts verify domains and configure SSO and directory sync, reached by a setup link that stays active for 30 days or until configuration is done. You may not build that, but design the handoff: a link or invitation the buyer can forward.
What order should setup follow?
Our suggestion is five steps in a fixed order: verify the domain, connect the identity provider, test with a real sign-in, choose who must use SSO, then switch on provisioning. Show the current step and the next one. The table lists the states behind those steps. Fill in its last column first, because recovery is what security reviewers ask about.
| State | What the admin sees | What end users see | Recovery |
|---|---|---|---|
| Locked by plan | What SSO covers, which plan includes it, a contact | Normal sign-in | Upgrade or contact sales |
| Domain pending | “Waiting for DNS. Usually minutes, up to 72 hours,” a re-check button, code expiry date | Normal sign-in | Re-check, or generate a new code |
| Domain verified, no provider | Next step: connect | Normal sign-in | None needed |
| Connected, not tested | Test button, a named test user | Normal sign-in | Edit or delete the connection |
| Tested, optional | “SSO works. Not required yet.” | An SSO option beside existing methods | Turn the option off |
| Enforced | Who is required, who is exempt, fallback owners | SSO page only, plus a short explanation | Fallback owner signs in and turns enforcement off |
| Verification lapsed | Warning, the missing DNS record, a deadline | May skip SSO or be blocked, as you decide | Restore the record, re-check |
| Certificate expiring | Date, who was told, an upload button | Normal until expiry | Upload the new certificate |
| Provisioning failing | Last good sync, cause in plain words | Leavers keep access until the next good sync; new hires wait | Replace credentials, re-test, resync |
How should domain verification and claim work?
Notion gives an organization owner a DNS code. A DNS change usually takes minutes but can take up to 72 hours, the code expires after a week, and a domain does not cover its subdomains. Atlassian offers an HTTPS file or a DNS TXT record, also up to 72 hours. If the record later disappears, it emails a deadline, after which the domain loses verification and policies for it, “including SAML single sign-on,” stop taking effect. It suggests using both methods as a backup.
Verification is a state that can lapse, so show it on the SSO screen and email admins when it changes. Claiming a domain can also surprise: Atlassian warns that an admin may see more accounts than expected, because anyone can create an account, and it notifies the users it claims. Notion emails owners of existing workspaces on a verified domain, then waits 14 days before those workspaces become claimable. We suggest listing the existing accounts and workspaces before the admin confirms a claim.
How can an admin test a connection before enforcing it?
Vendors use four patterns. GitHub’s enterprise SAML setup runs a Test SAML configuration check that must succeed before the settings can be saved. Atlassian’s SAML guide tests on a policy that covers one user, or with a temporary account on an unverified domain, and notes that saving does not log out current users. Figma says its login-method setting can stay on “any method” during configuration to prevent lockouts. On the provisioning side, Microsoft Entra offers Provision on demand, which provisions one user in seconds to validate expressions and scoping filters.
We suggest that a test is a real sign-in by a named person, and that the result names one cause: “Sign-in worked, but the response has no email address.” Keep saving and enforcing apart, as separate and clearly labeled decisions.
How do you enforce SSO without locking everyone out?
The vendors read for this guide differ on four points: what happens to people already signed in, who is exempt, who can get back in, and how they are told.
- Slack lets owners choose required for all, required except guests, or optional. People already signed in stay signed in, and required members get an email asking them to bind their account within 72 hours. Owners can bypass SSO with email and password.
- Notion’s “Only SAML SSO” setting logs workspace users out so they sign in again, applies only to verified-domain members, and lets owners keep email and password sign-in to fix a failing provider.
- Linear does not log sessions out when SAML is enabled, and says admins and owners may have other login methods to prevent lockouts.
- GitHub asks owners to save recovery codes during setup. Each works once, in order, and grants access for 24 hours. Enforcing at organization level removes members who have not authenticated through the provider.
- Figma exempts guests. Linear and Slack treat them separately too.
Our suggestions: show a preview before the final click (how many people must sign in again, how many are exempt, who the fallback owners are), require recovery codes or a named fallback owner before enforcement can start, and roll out by group where the data model allows it. Atlassian policies can cover subsets of users, and Google assigns SSO profiles to organizational units or groups. Record every change here as an event; our audit log guide has the schema.
Should accounts be created just in time or through SCIM?
Just-in-time provisioning creates an account at a person’s first SSO sign-in. SCIM, the System for Cross-domain Identity Management, lets the identity provider create, update and deactivate accounts on its own schedule. The vendors read here set different limits.
Linear fills a JIT profile only at creation, and later sign-ins do not update it. Atlassian’s JIT works only when SSO is enforced on the default policy; otherwise it points to SCIM. Notion does not recommend JIT beside SCIM, because an allowed email domain can let people in who are not in the identity provider. Slack bills members added by SCIM as soon as they first sign in.
In our reading, JIT has no leaver event: the identity provider can stop sign-ins, but nothing tells your product the person left. Say that on the screen. When the admin picks SCIM, show the endpoint and token, who can see the token, and what happens to it when its creator leaves. Notion revokes a token when the owner who made it leaves or changes role, and every integration using it stops until a new token replaces it.
What happens when someone is removed, and what happens to their content?
RFC 7643 defines the active attribute and gives the typical example: false means the account is suspended, true means the person can log in. RFC 7644 lets a provider “choose not to permanently delete” a resource it was told to delete. So removal is not one thing, and vendors differ.
| Decision | What vendors do | What to specify |
|---|---|---|
| When does access end? | Notion’s SCIM removal logs the user out of all active sessions. Atlassian says a deactivated account loses access immediately | State whether open sessions end |
| Is the account kept? | GitHub says a deprovisioned managed account is never deleted. Atlassian’s delete waits 14 days, then shows “Former user” | Offer suspend and delete as separate actions |
| Can it be undone? | GitHub restores a soft-deprovisioned user; a hard-deprovisioned one needs a new account. Atlassian lets admins reactivate and cancel deletion within 14 days | Name the window and who can undo |
| Who keeps the content? | Atlassian keeps pages, issues and comments after a delete. GitHub deletes repositories a hard-deprovisioned user owns and retains their comments | Ask for a new owner before access ends |
| What do others see? | Atlassian adds “(Deactivated)” to the name | Pick a label and use it everywhere |
| Who is told? | Atlassian emails the deactivated user | Send admins a digest of removals |
Content ownership should be settled before removal, not after; a queue of “items owned by removed people” is our suggestion. The trigger also varies by identity provider: GitHub lists Okta as sending only soft-deprovisioning calls, so the same product can behave differently for two customers.
How should group-to-role mapping appear?
Linear’s SCIM maps pushed groups to teams. It also reads groups named linear-admins and linear-guests, plus linear-owners on Enterprise, to set roles, and once linked, admin and guest roles can no longer be edited by hand. Notion’s SCIM accepts a role attribute whose values include owner, and it refuses to delete a group if that would leave a page with nobody holding full access.
Design rules that follow (ours): mark every role set by a directory with its source (“Managed by group marlowe-approvers”), disable the control and say why, decide whether the identity provider may grant your top role, define the winner when a person is in two groups, and set a default for people in no group. For the role model itself, see our roles and permissions guide.
Which error and expiry states need a screen?
Four sources of failure deserve their own states: certificates, domain verification, provisioning and credentials.
On certificates, Microsoft Entra’s certificate guide says its SAML certificates last three years by default and that it emails 60, 30 and 7 days ahead, by default only to the admin who added the application, with up to five addresses allowed. It advises vendors to accept a primary and a secondary certificate and to check metadata at least every 24 hours. Google also accepts two. GitHub does not enforce certificate expiry, but a regenerated certificate that was never updated causes a digest mismatch error. Your product should show the expiry date and notify every admin, not only the person who set it up.
For a lapsed domain, show the missing record and the deadline, as described above.
On provisioning, Entra puts a failing job into quarantine, cuts its sync cycles to one a day, and disables it after more than four weeks. Your screen should show last good sync, cause in plain words and what is waiting.
On credentials, a SCIM token tied to a person breaks when that person leaves, as in the Notion case above. Show who created each token and warn before they go.
How should plan gating work?
Slack lists SAML and SCIM for Business+ and Enterprise. Notion offers SAML on Business and Enterprise, but SCIM and multiple identity providers only on Enterprise. Linear gates both to Enterprise, and when a workspace moves to a plan without them, new SCIM provisioning stops while people already provisioned keep signing in. The third-party list sso.tax argues SSO should be in every plan or sold at a reasonable price; its rows carry their own dates, from 2018 to 2026.
Whichever choice you make, put it where reviewers look. Name the plan on the setup screen, list what SSO and SCIM include, and write down what a downgrade does before a customer meets it.
Illustrative worked example: a finance team moves to Enterprise
Everything here is invented. Marlowe Ledger is a fictional invoice-approval product. Tarnby Freight, a fictional customer, has 380 employees and is upgrading from Business. The buyer, Rhea Okoro, forwards the setup link to IT admin Dara Quill.
Dara adds a DNS record at 10:05. The screen says “Waiting for DNS. Usually minutes, up to 72 hours. Checking again in 5 minutes,” and shows verified at 10:40. The first test fails with “Sign-in worked, but the response has no email address. Map the email attribute and test again.” The second passes.
The enforcement dialog reads: “Require SSO for 380 people with tarnby.example addresses. 6 guests keep their current sign-in. People signed in now stay signed in until their session ends. Fallback owners: Rhea Okoro and Dara Quill. Recovery codes: downloaded.” Enforcement starts once Dara confirms the recovery codes are saved.
Provisioning follows. The group marlowe-approvers maps to the Approver role, so the role menu for those people reads “Managed by group marlowe-approvers.” When Jo Marsh leaves, the sync suspends the account at 17:02 and signs out open sessions. The admin screen shows “14 approvals need a new owner” with Rhea Okoro as the default. Thirty days before the provider’s certificate expires, a banner asks for the new one, and the email goes to both owners.
Where do these defaults stop working?
The sources are vendor documentation, two RFCs and one third-party price list. They show how products behave, not how admins perform on your screens; no study of SSO or SCIM setup flows in B2B products was found, and none is claimed. The flows here are mostly SAML. Google Workspace, for one, supports both SAML and OIDC profiles, and OIDC setup is not covered in depth. Behavior also varies by identity provider and plan, as the GitHub deprovisioning rules show. Legal duties for retaining or deleting a leaver’s data, regional rules and certification audits are out of scope.
What can you produce now?
Six things, before anyone draws a screen:
- The setup-state worksheet, filled in for your product, with a recovery for every state.
- A copy deck for every error: domain, test, certificate, provisioning.
- An enforcement spec: exemptions, fallback owners, recovery codes, what happens to open sessions.
- A deprovisioning table: suspend or delete, who inherits content, how long undo lasts, who is told.
- A role-mapping spec: source labels, conflicts, defaults and the top-role rule.
- A plan statement for the setup screen, the pricing page and the downgrade flow.
If you plan to bring in outside designers, ask each team to fill in the state worksheet for your product and explain the enforcement dialog. Our comparison of UX/UI agencies that design complex B2B SaaS platforms shows which studios publish work on screens like these.
