How SSO, SCIM, and HR sync work together

Last updated: November 10, 2026

Span uses three separate connections to manage people. HR sync decides who is in Span, SCIM decides who can use Span, and single sign-on (SSO) decides how they sign in. This article explains how the three fit together, and what happens when they disagree.

Why it matters

The three are often set up by different people, and often in the same tool. Okta, for example, can do all three. When someone can't sign in, is missing from a team, or still has access after leaving, the cause is usually that one connection was expected to do another's job.

For IT admins: know which system to change when someone joins, moves, or leaves.
For Span admins: know why a person can be in your roster but unable to sign in, or able to sign in but missing from their team.

How it works

Three jobs, three connections

Connection	What it controls	Set up in Span at	What it never does
HR sync (your HR system, or the Span Sync API)	Who is in your roster: people, managers, start and termination dates, and optionally teams	Settings → Integrations	Grant anyone sign-in access
SCIM provisioning	Who can sign in: each person's Access Type (Account or No account)	Settings → SCIM Setup	Create people, or set teams, managers, or permissions
Single sign-on (SSO)	How people sign in: through your identity provider instead of an emailed code or Google	Settings → Single Sign-On	Create people or grant access

Without HR sync, you can keep the roster by hand or by CSV. Without SCIM, an admin sets Access Type in Settings → People Management. Without SSO, people sign in with an emailed 6-digit code or Google. You can use any one of the three without the others.

How they connect

All three match people by email address, ignoring capitalization. Each one acts only on someone the step before it has already set up:

**HR sync adds the person** to your roster. People who arrive this way don't have sign-in access yet.
**SCIM turns on access.** When the person is assigned to the Span app in your identity provider, Span finds the roster person with the same email and sets their Access Type to Account. If no roster person has that email, nothing happens.
**SSO signs them in.** On the Span sign-in page, an email on one of your registered domains goes to your identity provider. Span then looks up the person by the email the identity provider sends. Sign-in works only if that person is in your roster, is not terminated, and has Access Type Account.

What each system decides about permissions

None of the three assigns permission groups directly. Your HR data still shapes them. Anyone with direct reports joins the Managers group automatically, and a permission group can add people by rules on job title, job family, or level. Everything else is assigned in Span. See Roles & Permissions in Span.

Joining, moving, and leaving

Event	Change it in	What happens in Span
New hire	Your HR system, then assign them to the Span app in your identity provider	HR sync adds them to the roster. SCIM gives them access. They sign in through SSO.
Team or manager change	Your HR system	The next HR sync updates their team or manager. SCIM and SSO don't change.
Email change	Your HR system and your identity provider, together	Every connection matches by email, so a change in only one place breaks the match. See Things to know.
Leaver	Your HR system and your identity provider	HR sync terminates them and keeps their history. SCIM removes their access. A terminated person can't sign in, even if your identity provider still lets them through.

When the systems disagree

Situation	Result
Assigned to the Span app in your identity provider, but not in your Span roster	No access. SCIM finds no one to match, and SSO sign-in fails with "Account does not exist." Add them to the roster through HR sync, CSV, or by hand.
In your roster, but not assigned in your identity provider	If SCIM has never managed them, they keep the Access Type an admin set. If SCIM did manage them, removing the assignment removes their access.
Terminated in your HR system, still assigned in your identity provider	They can't sign in, because Span blocks sign-in for terminated people. Their history stays. Remove the assignment as well, to keep your identity provider tidy.
Deactivated in your identity provider, still active in your HR system	They lose access, but still count as active in your metrics until your HR system ends their employment.
Different email in your HR system and your identity provider	SCIM doesn't give them access, and SSO sign-in fails. Make the two match.

Setup

Set the three up in this order, so each step has the people it needs:

**Connect your HR system**, or another roster source. Go to **Settings → Integrations**, connect your HR system, and choose the departments to sync. Span reviews the data with you before your roster changes. See [++People Data & Roster Management++](https://help.span.app/articles/1167228344-people-data-roster-management).
**Set up SCIM** if you want your identity provider to control access. Go to **Settings → SCIM Setup**, connect your identity provider, assign the Span app, and ask your Span account team to turn on provisioning. See [++Setting Up SCIM Provisioning for Span++](https://help.span.app/articles/9945474770-setting-up-scim-provisioning-for-span-via-workos).
**Set up SSO.** Confirm your email domains with your Span account team, then go to **Settings → Single Sign-On** and finish a test sign-in. See [++Setting up SSO with Span++](https://help.span.app/articles/8449989940-setting-up-sso-with-span).

All three setup pages need the Manage Integrations permission, which Owners, Admins, and Integration Admins have by default.

Things to know

Email is the key everywhere. If someone's email changes, update it in your HR system and your identity provider together. With HRIS sync, a changed email can create a second record for the same person; contact support to merge them.
Okta can do all three, and each is a separate setup. Okta as an HR source brings in people data. Okta SCIM controls access. Okta SSO controls sign-in. Connecting one doesn't connect the others.
Timing differs. SSO applies at each sign-in. SCIM changes usually arrive within minutes, and Span also re-checks every SCIM assignment once a day. HR sync changes wait in Settings → Directory Sync for an admin to apply them, unless Span has turned on auto-apply for your organization.
SCIM-managed access is locked in Span. An admin can't change Access Type for someone SCIM manages. Change the assignment in your identity provider.
SSO covers your registered domains only. People on other domains, such as contractors, keep signing in with the emailed code or Google.
Worked example. Priya joins Engineering. HR adds her to Workday on Monday, and the next applied sync adds her to your Span roster, with Lee as her manager. IT assigns her to the Span app in Okta, and SCIM sets her Access Type to Account within minutes. She signs in through Okta SSO, and because she has no direct reports she lands in Team Members. Lee sees her in his reports. Months later, Priya changes her email to a new domain alias in Okta only. SSO now sends the new address, Span can't match it, and she sees "Account does not exist" until her email in Workday is updated to match.