Enterprise SSO & SCIM (Directory Sync) for Admins

What SSO and SCIM give you

SSO lets your team sign in to Sybill using your existing identity provider — Okta, Microsoft Entra ID (Azure AD), or any SAML provider. You can optionally require SSO so members can no longer sign in with a personal Google or Microsoft login.

SCIM directory sync connects Sybill to your IdP's user directory. When someone is added to, moved between, or removed from your groups, Sybill updates their seat and role automatically — no manual invites or offboarding.

Two concepts worth knowing before you start:

Your IdP verifies identity; Sybill still runs your session. Turning on SSO doesn't change your data or your recordings — it only changes how people prove who they are at login.
Your connected calendar is your Sybill identity. Every user connects a Google or Outlook calendar the first time they sign in with SSO. This is required — see the note in Part 1.

Before you begin

You need the Admin role in Sybill (Admins have access to Admin and Billing settings).
Enterprise SSO and SCIM are available on eligible plans. If you don't see the Single sign-on card described below, your plan may not include it yet — contact your Sybill account team.
Have your IT admin ready. They'll complete the identity-provider configuration in Part 1 and (for SCIM) Part 3.
Decide up front whether you'll require SSO (Part 2) and whether you'll use SCIM directory sync (Part 3). SCIM requires SSO to be required.

Who does what:

You (workspace admin): start setup, send the IT admin their link, flip the toggles, map groups.
Your IT admin: configure the SAML connection and (for SCIM) the directory in the setup portal we generate for them.

Part 1 — Set up SSO login

1. Open the SSO card. Go to Settings > Admin > Company Profile and find the Single sign-on (SSO) card. Click Set up SSO.

2. Send your IT admin the setup link. In the card, enter your IT admin's email and click Send setup link, or screen-share and walk them through it live. The emailed link is a secure Sybill link valid for 30 days; each click opens a fresh configuration session.

Note: Always use the Sybill setup link. The underlying provider links expire within minutes and can't be emailed directly.

3. Your IT admin configures the connection. In the setup portal, your IT admin selects your identity provider and exchanges the SAML metadata. Ask them to follow this checklist:

Assign your users to the Sybill application in your IdP. App assignment is what grants access.
Send the email attribute — this is required. In Okta: Sign On > Attribute statements, name email, value user.profile.email.
Send an externalId attribute (strongly recommended) — name externalId, value user.id. This gives Sybill a stable identifier that survives email changes and renames.
Don't change the NameID format. The default email-format NameID is what Sybill expects.
The NameID must be each user's own email — never a fixed value or a per-app username override. A static or shared application username sends every employee in as the same person. If your IdP allows per-assignment username overrides, leave them unset.

4. Activate and test. Once your IT admin finishes, the card automatically flips to Active — no further action needed. Click Test SSO to run a sign-in end to end.

Note: connecting a calendar is required. The first time each person signs in with SSO, they'll be asked to connect their Google or Outlook calendar before they finish signing in. This is expected and only happens once per user. Let your team know so it isn't a surprise.

Once SSO is active, members can also sign in by typing their work email on the Sybill login page — Sybill recognizes your domain and routes them to your IdP automatically.

Note: By default, only users on your email domain(s) can sign in through SSO. To allow external collaborators on other domains, contact your Sybill account team.

Part 2 — Require SSO (optional enforcement)

By default, turning on SSO adds a sign-in option — members can still use Google or Microsoft login. When you're ready to make SSO the only way in, turn on Require SSO in the same card.

What changes when Require SSO is on:

Members can no longer sign in with a personal Google or Microsoft account — they're redirected to your IdP.
Connecting a calendar or email integration from Settings still works (this is intentionally exempt).

Before you turn it on, confirm:

SSO shows Active and every current member has completed at least one SSO sign-in (or is assigned in your IdP with a calendar connected).
You've inventoried any service or automation accounts that sign in with Google or Microsoft — they will be blocked. Move them onto SSO or plan around them first.
Your team knows that regaining access if you're locked out of your IdP is handled by Sybill support — it isn't self-service, by design.

Note: There's no separate confirmation step — the toggle takes effect immediately. Large workspaces take up to a minute to finish applying.

Part 3 — Automatic provisioning with SCIM (Directory Sync)

SCIM keeps Sybill's members, seats, and roles in sync with your IdP directory.

Prerequisite: Require SSO must be on before you can enable SCIM. (While SCIM is on, Require SSO stays locked on — turn SCIM off first if you ever need to relax the SSO requirement.)

1. Set up directory sync. In the SSO card, click Set up directory sync. This opens a portal for your IT admin to configure SCIM in your IdP. (This is separate from the SSO connection in Part 1.)

Ask your IT admin to confirm, in the SCIM app's provisioning settings:

The userName and email attribute mappings are enabled. In Okta these are on by default — don't remove them. Sybill matches directory users by email; a user provisioned without an email won't sync.
Users are assigned to the SCIM app. Only assigned users appear in your directory.
Both groups you plan to map are pushed to the app (in Okta: Push Groups).

2. Map your groups. Once the directory is connected, choose two groups from your directory:

Paid seats group — members of this group get a Recorder seat (they can record and manage meetings).
Admins group — members of this group get the Admin role.

The two groups must be different. Click Save mappings.

Note: Changing which group is your paid-seats group later re-applies seats for everyone on the next sync — people in the old group lose their seats, people in the new group gain them. Treat a mapping change as a bulk license change, not a rename.

3. Turn on Sync members from directory. Enabling it imports everyone already in your directory and keeps them in sync going forward.

How fast do changes apply?

Change	Typical	Worst case
Group membership change (seat or role)	Seconds	Within 5 minutes
New user added to the directory	Seconds	Within 5 minutes
User removed or deactivated	Seconds	Within 5 minutes
Full directory audit (catches anything missed, upgrades waiting users)	Hourly	—

How directory membership maps to Sybill:

In your IdP directory	In Sybill
Added to the paid seats group	Gets a Recorder seat (if a seat is available — see Part 4)
Removed from the paid seats group	Becomes a free Collaborator
Added to the admins group	Becomes an Admin
Removed from the admins group	Returns to Member
New user in the directory	Added to Sybill as a free Collaborator
Removed or deactivated in the directory	Access removed — see Part 5

Note: your directory is the source of truth for everyone in it. If you manually make someone a Recorder in Sybill but they aren't in your paid-seats group, the next sync returns them to Collaborator. Manage seats and roles through your IdP groups once SCIM is on. The reverse is also true: members who exist in Sybill but were never added to your directory (for example, members from before SSO who aren't assigned to the app) are left alone — sync never removes someone just for being absent from the directory.

Part 4 — Seats and billing

Recorder seats are the paid seats on your plan; Collaborators are always free. With SCIM on, seats follow your paid-seats group — with a few behaviors worth understanding.

Your paid-seats group can be larger than the number of seats you've purchased. That's a normal, supported state — not an error.
At your seat limit, the next person stays a free Collaborator and your admins get an email letting you know you're out of seats (sent at most once a day). They keep full Collaborator access; they just don't hold a Recorder seat yet.
Sybill never charges you automatically for a directory change. Adding someone to the paid group never expands your subscription on its own — you're always in control of your seat count.
When a seat opens up — because you purchased more or someone was removed — waiting users are upgraded automatically as seats become available, usually within an hour. It isn't instant.

Note: If you buy seats (or free one up) and a paid-group member is still showing as a Collaborator, give it up to an hour to catch up.

To change how many Recorder seats you've purchased, go to Settings > Billing.

Part 5 — Removing and reactivating users

When someone is removed or deactivated in your IdP directory, Sybill automatically offboards them:

Their Recorder seat is freed.
Their Admin role is removed.
Sybill's access to their Google/Outlook/Zoho mail and calendar is revoked, and they can no longer sign in.

Note: removing many people at once? As a safeguard against IdP misconfiguration, large batches of removals are not applied fully automatically — Sybill applies a few per sync cycle and holds the rest for an Admin to review and confirm from the directory sync panel. (Microsoft Entra's provisioning has a similar accidental-deletion threshold.) Single removals apply immediately.

Note: existing sessions end at expiry. Removing a user immediately blocks new sign-ins and cuts off Sybill's access to their mail and calendar. However, a session that's already open may keep working until its sign-in token expires. If you need a user's access cut off immediately (for example, an urgent security offboarding), contact Sybill support.

Reactivating a user

Deactivation is intentionally one-way — re-adding a person in your IdP alone will not restore their Sybill account. Reactivation is a three-step process, in this order:

Reactivate them in your IdP first — reassign the Sybill app and re-add their groups. If you skip this step, the next sync will deactivate them again.
A Sybill Admin restores their membership under Settings > Admin > Team Management (Deactivated tab → Reactivate). Their seat and role then follow your IdP groups as usual.
Contact Sybill support to re-enable their sign-in. For security, sign-in for a deactivated user stays locked until our team confirms the reactivation — this final step is not self-service, by design.

After reactivation, the user will be asked to reconnect their calendar and email the next time they sign in. This is expected — their previous authorizations were revoked when they were offboarded.

If a user reports being unexpectedly locked out, confirm the IdP change was intended before treating it as final.

Optional settings

Protect your domain from new workspaces. You can ask Sybill to verify your email domain, which prevents anyone from creating a separate Sybill workspace on that domain. This is a safeguard against shadow accounts. Verifying locks the domain right away; to unlock it later, contact Sybill support. Ask your Sybill account team to verify a domain.

Pause new-member provisioning. Turn on Pause new member provisioning if you don't want people auto-created in Sybill on their first SSO sign-in. Existing members are unaffected — their seats and roles keep syncing. When you turn it back off, anyone added to the directory while paused is created automatically, within about an hour.

Troubleshooting & FAQ

I don't see the Single sign-on card. It appears under Settings > Admin > Company Profile for Admins on eligible plans. If it's missing, confirm you have the Admin role and check with your Sybill account team about plan availability.

A user is stuck at "connect your calendar." This is expected on a first SSO sign-in — connecting a Google or Outlook calendar is required before provisioning completes. Once they connect, they'll continue automatically. It only happens once.

A user sees "Profile domain does not belong to the target Organization." Their email domain isn't on your workspace's allowed list. SSO is limited to your verified domain(s) by default — contact your Sybill account team to add a domain or allow external collaborators.

I changed someone's group in the IdP but nothing happened in Sybill. Changes normally apply within seconds and at most a few minutes. If it's been longer: confirm the user is assigned to the SCIM app, the group is pushed to the app, and the group is one of your two mapped groups. Changes to unmapped groups are ignored by design.

I added seats but someone in the paid group is still a Collaborator. Seat upgrades apply within about an hour of a seat becoming available. If it's been longer, contact support.

I removed a user but they could still see data for a little while. New sign-ins are blocked immediately, but an already-open session can persist until its token expires. For immediate cutoff, contact Sybill support.

I removed a batch of users and only some were offboarded. That's the bulk-removal safeguard (see Part 5). An Admin can review and apply the remaining removals from the directory sync panel, or they'll continue applying gradually.

I rehired someone (or removed them by mistake) and they can't sign in. Reactivation is a three-step process — IdP first, then Team Management, then a note to Sybill support to re-enable sign-in. See Part 5. Re-adding them in your IdP alone won't restore access.

Can external contractors on other domains sign in with our SSO? Not by default — SSO is limited to your verified domain(s). Contact your Sybill account team if you need to allow external collaborators.

Can I turn off Require SSO while SCIM is on? Turn off Sync members from directory first, then Require SSO. SCIM depends on SSO being required.

User Roles, License Types and Permissions
Upgrading your Plan & Adding Team Members to Sybill
Transferring Recorder Licenses Between Users