SCIM provisioning for your LMS: joiners, movers and leavers

SSO decides who can sign in to your LMS. SCIM decides who has an account in it at all. With SCIM, your identity provider (Okta or Microsoft Entra ID) creates LMS accounts for new hires, updates department and manager when people change roles, and deactivates leavers without anyone opening the LMS admin. Use both: SAML for sign-in, SCIM for the account lifecycle.

LMS Advisor supports both: SAML 2.0 SSO for sign-in and a SCIM 2.0 endpoint your identity provider calls to manage accounts, which land in the branches, organizations and groups you've already set up.

That split is the whole idea behind a SCIM provisioning LMS setup, and it's the part most vendor setup pages skip. They show you where to paste a URL, not what happens to a leaver's compliance records or which admin account you'll need the day your IdP certificate expires. This guide covers both, with the Okta and Entra steps in between.

Why do SSO and SCIM do different jobs?

SAML single sign-on is an authentication handshake. The LMS sends the user to the identity provider (IdP), which confirms who they are and returns a signed assertion. Nothing happens until a person tries to sign in.

SCIM works the other way around. Okta's developer guide to SCIM describes it as an open standard that provides "a defined schema for representing users and groups, and a RESTful API" to create, read, update and delete those resources. The protocol itself is RFC 7644, which defines the /Users and /Groups endpoints. The IdP calls the LMS on its own schedule, whether or not the person ever signs in.

So SSO alone leaves a gap. If a sales rep leaves on Friday and IT disables them in Entra, they can't sign in to the LMS again. But their LMS account still exists, still shows as active, may still count toward your license, and still sits in the overdue report for the harassment-prevention course they'll never finish. In our migration work, the cleanup usually falls to an L&D admin working from a monthly HR spreadsheet, if it gets sent.

What does SCIM automate for joiners, movers and leavers?

Here's what each stage of the joiner, mover, leaver cycle looks like in an LMS, with and without SCIM.

Stage	What SCIM does	What happens without it
Joiner	Creates the LMS account when the person is assigned to the app, with name, email, department and manager filled in	Account appears only at first sign-in (JIT) or when an admin uploads a CSV, so onboarding assignments can't start on day one
Mover	Sends a PATCH with the new department, title or manager, so reports and manager views follow the person	The learner keeps reporting to their old manager and old department until someone notices
Leaver	Sets active=false on the LMS account when the assignment is removed	The account stays active, may consume a seat, and keeps showing up as overdue in compliance reports
Rehire	Sets active=true on the same account, so prior training history comes back with the person	A second account gets created, and the history is split across two records

Why the leaver step matters most

Leavers are where the money and the audit risk sit. If your LMS contract bills on registered or active users (check yours), an account nobody deactivated can be a seat you pay for every month.

The audit side is subtler. You want the leaver locked out, but you don't want their records gone. If a regulator or plaintiff asks in two years whether that manager completed their training, you need the completion, the date and the certificate. Our table of training records retention requirements shows how long several US rules expect you to keep them. That's why soft delete (deactivate, keep the record) is the right default for an LMS.

Both big IdPs lean that way. Okta's provisioning overview says that when an assignment is removed, "Okta doesn't delete the user's account. The account is put into a deactivated state in the external app." Microsoft's guide to building a SCIM endpoint for Entra ID supports both a soft delete (active=false) and a hard DELETE request, so check which one your connection sends before you go live.

How do you set up SAML SSO with Okta or Microsoft Entra ID?

Set up SSO first and prove it works for one test user. Every SAML setup trades the same few values. The LMS (the service provider) gives the IdP its Entity ID and its Assertion Consumer Service (ACS) URL. The IdP gives the LMS its own entity ID, its sign-in URL and a signing certificate, usually bundled in a metadata URL or XML file. Keep both sets of values in your change ticket. You'll want them when the certificate needs rotating.

Okta

1. In the Admin Console, open Applications and select Create App Integration, then choose SAML 2.0.
2. On the Configure SAML tab, enter the LMS's ACS URL in Single sign-on URL and its entity ID in Audience URI (SP Entity ID).
3. Pick a Name ID format and Application username. Email works for most LMSs, as long as it's the same value SCIM will send as the username later.
4. Add Attribute Statements for first name, last name and email if the LMS reads them from the assertion.
5. After saving, go to the Sign On tab and copy the Metadata URL, or open "More details" for the individual URLs and certificate.
6. Assign a test user under Assignments.

These field names come from Okta's guide to building a SAML integration. When a sign-in fails, check Reports > System Log for the error code.

Microsoft Entra ID

1. In the Microsoft Entra admin center, go to Entra ID > Enterprise apps > All applications and open the LMS app.
2. Under Manage, select Single sign-on, then SAML.
3. Edit Basic SAML Configuration: Identifier (Entity ID), Reply URL (the ACS URL) and Sign on URL (the LMS login page).
4. Download the signing certificate from the SAML Certificates section, or copy the federation metadata URL if your LMS accepts one.
5. Assign a test user, then use the Test button on the same page.

Microsoft's steps for enabling SAML single sign-on on an enterprise app note that you need at least the Cloud Application Administrator role, and that SAML is only configurable on single-tenant or gallery apps.

What goes on the LMS side

Paste the IdP's metadata URL (or entity ID, SSO URL and certificate) into the LMS's SAML settings. Then decide whether SSO is required for your employee domain or just offered. Required is cleaner for security reviews. Offered is safer for the first week.

How do you connect SCIM provisioning and map attributes?

SCIM needs two things from the LMS: a base URL for its SCIM endpoint and a credential, usually a bearer token. Treat that token like a service account password, with a named owner and a rotation date.

Okta

According to Okta's help page on adding SCIM provisioning to an app integration, you set Provisioning to SCIM on the General tab, then on the Provisioning tab enter the SCIM connector base URL and the unique identifier field (commonly userName). You choose supported actions, such as Push New Users, Push Profile Updates and Push Groups, and set the Authentication Mode. Pick HTTP Header if the LMS gave you a bearer token.

Microsoft Entra ID

Open the same enterprise app and select Provisioning. Per Microsoft's steps for automatic provisioning, set Mode to Automatic, expand Admin Credentials, enter the SCIM endpoint URL (Tenant URL) and token (Secret Token) the LMS gave you, and select Test Connection. Review Mappings and scope, then set Provisioning Status to On. Entra runs an initial cycle and then, per Microsoft's SCIM guide, incremental cycles "approximately every 40 minutes." That number matters for leavers, as we'll see in the testing section.

Which attributes should you map?

Map only what the LMS will use. Here are Entra's default mappings, with what each should drive in an LMS:

Entra attribute	SCIM attribute	What it should drive in the LMS
userPrincipalName	userName	The login identity. Must match the SAML Name ID, or users end up with two accounts
mailNickname	externalId	A stable key for matching, useful when emails change after a name change
givenName, surname	name.givenName, name.familyName	Name on certificates and reports
mail	emails[type eq "work"].value	Where notification emails and certificates go
department	enterprise extension department	Department or group membership, and so which mandatory courses apply
manager	enterprise extension manager	Who sees this person in a manager view
IsSoftDeleted	active	Whether the account can sign in and whether it counts as a current learner

One trap we see in almost every migration: the LMS already has hundreds of accounts from CSV imports. Microsoft's guide says Entra queries users by userName and externalId before creating them. If the existing LMS usernames don't match what the IdP sends (say, old accounts use personal emails or a legacy employee ID), SCIM creates duplicates. Clean up usernames before the first sync, not after.

Just-in-time accounts or SCIM provisioning: which should you use?

Just-in-time (JIT) provisioning creates the LMS account the first time someone signs in through SAML, using the assertion's attributes. It needs nothing beyond SSO, which is why it's popular, and why most stale-account problems start there.

Question	JIT accounts	SCIM provisioning
When does the account appear?	At first sign-in	When the person is assigned to the app in the IdP
Can you assign day-one training before they log in?	No, there's no one to assign it to	Yes
When do department and manager update?	Only when the person signs in again, if at all	On the next sync cycle
What happens when someone leaves?	Nothing. They can't sign in, but the account stays active	Account is deactivated
Setup effort	Low	Moderate: endpoint, token, mappings, testing

JIT is fine for a small pilot. For company-wide compliance training, it falls short. The whole point of an overdue report is that it includes people who haven't signed in. JIT can't show you anyone who never did.

How should you test the setup before switching everyone over?

Run this with two test accounts and one pilot group, in this order.

1. SP-initiated sign-in. Open the LMS login page in a private window and choose SSO. You should land back in the LMS signed in as the test user.
2. IdP-initiated sign-in. Launch the LMS from the Okta End-User Dashboard tile or the Entra Test button. Some LMS setups work one way and not the other, so test both.
3. Joiner. Assign a brand-new test user. In Entra, use Provision on demand rather than waiting for the next cycle. It provisions one user in seconds and shows whether scoping filters let them through. Check the LMS for correct name, email, department and manager.
4. Mover. Change the test user's department and manager in the IdP. Confirm the LMS updates, and that the new manager can see them.
5. Leaver. Remove the user's assignment. Confirm the account shows as inactive, that sign-in fails, and that their completions and certificates are still there.
6. Rehire. Reassign the same user. You want one account reactivated with history intact, not a new one.
7. Existing accounts. Pick five users who already had LMS accounts before SCIM. Confirm they were matched, not duplicated.
8. Pilot group. Assign one real department, wait a full sync cycle, and compare the LMS user count with the IdP group count before assigning everyone.

Watch the timing in step 5. With a sync cycle around 40 minutes, a leaver's LMS account can stay active for a while. Blocking the IdP account stops new SSO sign-ins right away, but an open LMS session lives until it expires. If the LMS holds sensitive material, shorten its session lifetime and make disabling the IdP account step one of offboarding.

In our LMS implementation timeline, this testing sits in the integration weeks, before any learner-facing launch.

Which accounts should not depend on SSO?

Requiring SSO for employees is good practice. Requiring it for every account is how teams lock themselves out.

Break-glass admin accounts

Keep at least one LMS admin account that signs in locally, not through the IdP. You'll need it when a SAML signing certificate expires, when someone changes the Entity ID, or when the IdP has an outage the week of a compliance deadline. Microsoft's guidance on emergency access accounts is written for Entra itself, but it translates well: keep at least two, protect them with phishing-resistant methods like passkeys (FIDO2), don't tie them to one person, alert on every sign-in, and check they still work at least every 90 days.

People outside your directory

Contractors, franchise staff, customers and exam candidates often aren't in Okta or Entra, and shouldn't be added just for training. Give them local accounts protected by passkeys or two-factor authentication, and keep them in their own organization or group so their records never mix with employee reporting.

Be honest about single logout

Some LMSs support SAML single logout, where signing out of the IdP also ends the LMS session. Many don't, and LMS Advisor is one of them: we support SAML 2.0 sign-in, not single logout. In practice that means a shared device, such as a break-room PC on a plant floor, needs users to sign out of the LMS itself. Set a sensible session timeout, and tell reviewers plainly rather than letting them find it in a pen test.

How to run SSO and SCIM in LMS Advisor

Everything in this guide maps to settings you already have in LMS Advisor. Here's how the pieces line up with the steps above.

• Sign-in. SAML 2.0 SSO for your employee domain, set up with the IdP values from the Okta or Entra steps. Google sign-in is there too for teams that live in Google Workspace.
• Account lifecycle. A SCIM 2.0 endpoint your IdP calls for joiners, movers and leavers. Run the eight tests above against it with two test users before you assign a real department.
• Structure. Provisioned accounts sit in the model you set up in enterprise management: branches, organizations, departments, groups, roles and permissions, with manager views on top.
• Day-one training. Because SCIM creates the account before first sign-in, you can assign onboarding and mandatory courses with due dates and mandatory flags, and the overdue report shows who hasn't started.
• Accounts outside SSO. Break-glass admins, contractors and partners can use passkeys and two-factor authentication. Exam candidates sign in to the Test Center portal with an emailed one-time code, so they never need a directory account.
• Evidence and hosting. Audit logs are built in, and you can run in our cloud or self-host, as covered on our security and data ownership page.

The limits, up front: no SAML single logout, and HR sync connects only BambooHR, Zoho People and Keka. For Workday, ADP or another HR system, HR data reaches the LMS through your IdP, a CSV upload or the REST API, as our integrations page explains. Our security overview has what reviewers usually ask for, and our LMS RFP questions include the SCIM questions to ask any vendor, us included.

If you'd like to watch a leaver get deactivated with their records intact, using your own IdP tenant, book a demo and bring a test user.

Frequently asked questions

Does LMS Advisor support SCIM provisioning and SAML SSO?

Yes. LMS Advisor has a SCIM 2.0 endpoint for provisioning from your identity provider and SAML 2.0 for sign-in, plus Google sign-in, passkeys and two-factor authentication for other accounts. It doesn't support SAML single logout. HR data can also come straight from BambooHR, Zoho People or Keka through HR sync, or from a CSV upload for other HR systems.

Do I need SCIM if I already have SSO?

Yes, if you care about who is counted as a learner. SSO stops leavers from signing in, but it doesn't deactivate their LMS account, update their department or create accounts before first sign-in. SCIM handles all three, which is what keeps compliance reports and license counts accurate.

What happens to a leaver's training records when SCIM deactivates them?

With a soft delete, the records stay. The IdP sets active=false, the person can't sign in, and their completions and certificates remain available for audits. A hard DELETE is different, so confirm which one your IdP sends and what the LMS does with each before go-live.

How quickly does SCIM remove a leaver from the LMS?

It depends on the IdP's sync schedule. Microsoft documents incremental cycles roughly every 40 minutes for Entra ID. Disabling the person in the IdP blocks new SSO sign-ins immediately, so the practical gap is an already-open LMS session, which a shorter session timeout covers.

What is just-in-time provisioning in an LMS?

Just-in-time provisioning creates an LMS account the first time someone signs in through SSO. It's quick to set up but can't assign training before first sign-in, only updates attributes at sign-in and never deactivates leavers. Most companies use it for pilots and move to SCIM for full rollout.