An HR LMS connection works when four events in your HRIS each change the right fields in the LMS: a hire, a move, a leave, and a rehire. The HRIS owns who someone is, the LMS owns what they’ve completed, and neither system edits the other’s fields. Get one event wrong and it shows up at audit time, as a new hire with no account for three days or a leaver still listed as overdue in June. This guide gives you the field map, a test for each event, the route decision, and a checklist you can hand to whoever builds the connection.
Key Takeaways
- Ten fields go from the HRIS to the LMS, from employee ID to start date. Only completions and certificates should come back, and pay and performance ratings never leave the HRIS.
- Match people on employee ID, not email. When Microsoft Entra ID finds no match, it creates a new account, and the training history splits across two learners.
- A move should re-run assignment rules, and a rehire should reactivate the old learner. Test both, because vendor demos show the hire.
- Disable leavers, don’t delete them. In Microsoft Entra ID, a deleted user is deleted from connected SCIM apps 30 days later unless deletes are switched off for that app.
- If IT already feeds its identity provider from the HRIS, provision the LMS from the identity provider instead of building a second link to HR.
Want course completions to reach HR without anyone retyping them? See how Automations passes course events to the rest of your stack before you map the first field.
The Fields That Move From Your HRIS to Your LMS, and the Ones That Stay
An LMS needs about ten fields from the HRIS to assign the right training. It sends back one kind of data: what people completed. Everything else stays where it is, and this is the map to agree with your HRIS admin before anyone builds anything.
| Field | Owner | Direction | What the LMS uses it for |
|---|---|---|---|
| Employee ID | HRIS | HRIS → LMS | The key that ties every record to one person |
| First and last name | HRIS | HRIS → LMS | Certificates and reports |
| Work email | HRIS or identity provider | HRIS → LMS | Sign-in and reminders |
| Job title | HRIS | HRIS → LMS | Role-based assignment rules |
| Department | HRIS | HRIS → LMS | Learning paths and team reports |
| Manager | HRIS | HRIS → LMS | Manager views and overdue escalations |
| Location | HRIS | HRIS → LMS | Site-specific or state-specific courses |
| Worker type | HRIS | HRIS → LMS | Separate training for employees and contractors |
| Employment status | HRIS | HRIS → LMS | Whether the account is active, and who counts in compliance totals |
| Start date | HRIS | HRIS → LMS | Due dates for new-hire training |
| Completions, scores, certificates | LMS | LMS → HRIS or a report | Evidence HR has to hold |
Pay, bank details, benefits, and performance ratings stay off the list. SCIM, the standard that identity systems use to pass user accounts between apps, draws the same line. Its user schema (IETF RFC 7643) has fields for title, department, division, cost center, manager, employee number, and whether the account is active, but none for pay or performance. Every extra field you send is one more thing the LMS vendor holds and your security review asks about.
Every field has one editor. If a job title is wrong in the LMS, fix it in the HRIS. A title fixed only in the LMS gets overwritten on the next sync or drifts from HR’s version, and training gets assigned for the wrong job. If your LMS can lock synced fields, lock them.
Match on employee ID, not email. When Microsoft Entra ID provisions an app, it looks for an existing user through a matching attribute. If it finds none, it creates a new account. Work emails change after a name change, a domain move, or a rehire, and each change can produce a second learner holding half the history.
RFC 7643 describes the employee number as an identifier assigned to a person, “typically based on order of hire.” Ask the vendor whether the LMS can match on it. If it can only match on email, test what happens when an email changes before you go live.
Four Events, Four Jobs: Hire, Move, Leave, Rehire
A sync that only creates accounts handles one event out of four. Microsoft’s guide to HR-driven provisioning lists them as separate scenarios: new hires, updates to fields such as title or manager, terminations, and rehires. Each one changes different fields, so each one needs its own test. Run all four with one test employee before go-live.
Hire: the learner exists before day one
The trigger is a new record in the HRIS with a start date. By that date, the learner should exist with the paths their title, department, and location call for. Due dates should count from the start date, not from the day the account appeared. Otherwise a sync that runs three days late pushes every new-hire deadline three days past what HR expects.
Hires are what connector demos show. Docebo’s own HR case study describes Cineplex connecting its HRIS so that every new hire was added to the LMS automatically. Ask any vendor to show the other three events in the same demo.
Test: add a test employee who starts next Monday. By Friday, the account should exist with the right path, and the first due date should count from Monday.
Move: the assignment rules run again
A move is any change to title, department, manager, or location. It isn’t a smaller hire. The person already has a training history, and it has to survive the change.
Here’s a worked example. A support agent transfers to customer success, and HR updates the department field. In the LMS, four things should follow:
- The unfinished support escalation course stops being required.
- The customer success path is assigned, with due dates counted from the transfer date, not the hire date.
- The completed support training stays on the record.
- The agent shows up in the new manager’s report.
If the LMS only changes the department label, the agent keeps getting reminders for a course they no longer need. The new manager can’t see their progress either.
So ask the vendor. Do assignment rules re-run when a field changes, or only when an account is created? If it’s only on creation, every move needs a manual step. Name the person who takes it.
Test: change the test employee’s department and check all four outcomes after the next sync.
Leave: access stops, the record stays
The trigger is an employment status change to terminated, with a last day. After that day, sign-in should fail, reminders should stop, and the person should drop out of overdue totals. Their completions and certificates stay. An auditor asking about last year’s training still needs them.
How the account gets switched off, with and without SCIM, is covered in LMS SSO and auto-provisioning. Keeping the record is the harder part, and it has its own section below.
Test: terminate the test employee. After the next sync, sign-in fails, no reminder goes out, the person isn’t in the overdue report, and their certificate is still in their history.
Rehire: the old learner comes back
In Microsoft’s HR-driven setup, a rehire’s old account can be reactivated or reprovisioned. For an LMS, that choice decides what the person’s history looks like:
- Reactivated: the learner keeps their record, so courses that are still valid don’t have to be retaken.
- Created again: the new account starts empty, and one person’s audit trail sits across two records.
Refresher dates should still count from the original completions. A yearly safety refresher last done two years ago is overdue on day one back, not current.
Test: reactivate the test employee under the same employee ID. There should be one learner, with the old completions visible and the refresher dates unchanged.
Direct Link or Through Your Identity Provider
Before choosing a tool, find out whether the LMS needs to hear from the HRIS at all. If your company already feeds its identity provider from HR, it may not.
In that setup, Microsoft calls the HRIS “the source of authority” for identities. A hire creates the work account. A title or manager change updates it, and a termination disables it. Microsoft names Workday and SAP SuccessFactors as HR sources for Entra ID.
The identity provider then passes those changes on to each app over SCIM. The IETF wrote that protocol, RFC 7644, to move identity data between a company and its cloud services. Over that connection, Entra ID can create, update, and remove users in the LMS. Nobody has to touch it.
Pick the route with this rule:
- Your HRIS feeds Entra ID, Okta, or another identity provider, and the LMS supports SCIM on your plan: provision the LMS from the identity provider. File the request with IT, and ask them to add department, manager, title, and employee ID to the LMS app’s attribute mapping. Entra starts each app with a preset mapping, so check it carries every field your assignment rules read.
- The LMS has a native connector for your exact HRIS: use the direct link, and make the vendor demo all four events before you sign.
- Neither: you’re building it yourself, which the next section covers.
One gap stays open on every route. Identity provisioning moves people and HR fields into the LMS, but it doesn’t carry completions back to HR. That’s a separate connection, so plan it as its own row.
If There’s No HRIS Connector and No SCIM
Without either, each event becomes its own small build: a Zapier or Make automation, a script on the LMS API, or a named person’s weekly task. The trade-offs between those options are laid out in the four ways systems connect. What matters here is which event goes where.
| Event | Trigger | Action in the LMS | Manual fallback |
|---|---|---|---|
| Hire | New employee record in the HRIS | Create the learner, add them to a group or path | Weekly new-hire export, loaded by a named person |
| Move | Title, department, manager, or location changes | Update the fields, change the group | Weekly change report from the HRIS |
| Leave | Status changes to terminated | Deactivate the learner | A line in the offboarding checklist with an owner |
| Rehire | Status returns to active on an existing employee ID | Reactivate the learner | Same owner as leavers |
| Completion | Course completed in the LMS | Write the date to the HRIS or a shared sheet | Monthly completion export |
Three rules keep the build honest:
-
Check both ends before promising a row. The HRIS has to announce the change, and the LMS has to accept the action. If either one can’t, that row is a manual step, so find out before you tell HR that moves are automatic.
-
Look people up by employee ID in every step. An automation that searches by email and finds nobody will create someone new.
-
Never map “terminated” to “delete.” Map it to deactivate. The next section shows what a delete costs.
Automation platforms relay one event at a time, so they won’t pick up the people hired before the automation existed. Load current staff once with an import, then switch the automation on.
The weekly check. Whatever you automate, compare HRIS headcount with active LMS learners once a week. Any gap is a failed event. Put the check in the LMS administrator’s calendar with a name next to it.
After Someone Leaves: Disable the Account, Keep the Record
Removing access and removing the record are two decisions. An audit needs the record long after the access is gone. Microsoft draws the line clearly: a disabled user generally can’t sign in, while a deleted user “has been removed completely from the application.”
The delete runs on a timer. When someone is deleted in Microsoft Entra ID, they’re removed from the directory for good 30 days later. At that point, Entra sends the LMS a request to delete them too, unless Delete is switched off for that app. If the LMS treats it as a full delete, the leaver’s completions and certificates can go with the account.
Head this off before your first leaver. Ask IT to switch off Delete as a target action for the LMS app, or export each leaver’s training history before day 30.
“Deactivated” isn’t one fixed state either. The SCIM schema calls the active flag the user’s administrative status and leaves its “definitive meaning” to the service provider, which here means the LMS vendor. Get three answers in writing:
- What does an inactive learner keep: completions, scores, certificates, and a place in historical reports?
- Does an inactive learner count toward our user total?
- If a learner is deleted by mistake, can their history be restored or exported?
How long you keep leavers’ training records is your records policy’s decision, not the LMS default. Write that retention period next to the leave event in the checklist below.
The HR LMS Integration Checklist
Copy this table into the ticket or the project doc, and fill in the mechanism column for your stack. A row isn’t done until its test passes with the test employee.
| Event | Fields that change | Who writes | Mechanism (fill in) | Test that proves it |
|---|---|---|---|---|
| Hire | All ten inbound fields | HRIS | Account and path exist before the start date, and due dates count from it | |
| Move | Title, department, manager, location | HRIS | New path assigned, old requirement closed, history kept, new manager sees progress | |
| Leave | Employment status, last day | HRIS | Sign-in fails, reminders stop, out of overdue totals, certificate still on record | |
| Rehire | Employment status on the existing employee ID | HRIS | One learner, old completions visible, refresher dates unchanged | |
| Completion | Completion date, score, certificate | LMS | Record reaches the HRIS or report within the agreed time | |
| Weekly check | Headcount vs active learners | Named person | Manual | Numbers match, or each gap has a reason |
For the mechanism, pick one: identity provider over SCIM, native connector, automation platform, LMS API, or a named person. Before the build starts, get the HRIS admin and IT to agree on four points:
- Employee ID is the match key in every system and every automation.
- HR fields are read-only in the LMS.
- Terminated maps to deactivate, and deletes from the identity provider are off for the LMS.
- The retention period for leavers’ training records is written down.
Map the Fields Before You Build Anything
Send the field table to your HRIS admin this week and agree on employee ID as the match key. Then create one test employee and run the hire, move, leave, and rehire tests before anyone picks a tool. The results show which rows your current setup already handles and which ones need a build. Put the four tests in your LMS implementation plan as go-live checks, and check the delete setting before your first real leaver, not after.
Mini Course Generator is our product. It has no native HRIS connector and no SCIM provisioning. It passes course events to other systems through Zapier, Make, and webhooks, and its REST API is on the Custom plan listed on the pricing page. If you run it, put each HR event through the same rule as any other system: confirm the action exists before you mark the row automatic, and give the rest to the person who owns the weekly check.
Frequently Asked Questions
What is an HR LMS?
An HR LMS is a learning management system connected to the HR system, so hires, role changes, and leavers update training without anyone retyping a list of names. Some companies use the learning module inside their HR suite, and others connect a separate LMS to the HRIS they already run.
Do we need SCIM if we already have SSO?
SSO decides whether someone can sign in right now. It doesn’t create an account before day one, update a department, or switch off an account for a leaver who never signs in again. SCIM does those jobs, so if the LMS offers it on your plan and IT runs a provisioning service, use both.
How often should the HRIS sync to the LMS?
Often enough to meet your shortest new-hire deadline. If the first required course is due on day three, a weekly sync will miss it for some hires. Leavers set the other limit: decide how many days a former employee may keep a working account, and sync at least that often.
Should training completions be written back into the HRIS?
Only when HR has to act on them, for example when a completed course affects eligibility for a role or a license the company must hold. Otherwise a report HR can open is enough, and it avoids a second copy of the record that can drift.
Who decides how long to keep a leaver’s training records?
Not IT, and not the LMS vendor. IT controls whether deletes reach the LMS, and the vendor decides what an inactive learner keeps, but neither knows how long you may need proof of someone’s training. Ask whoever sets retention for your other employee records to set the period, then check that the LMS can hold inactive learners that long.
Sources
- IETF: RFC 7644, System for Cross-domain Identity Management: Protocol
- IETF: RFC 7643, System for Cross-domain Identity Management: Core Schema
- Microsoft Learn: What is HR-driven provisioning with Microsoft Entra ID?
- Microsoft Learn: Understand how application provisioning works in Microsoft Entra ID
