HRMS–LMS integration makes your HR system the single source of truth for people and your LMS the single source of truth for learning, then keeps them in agreement automatically. People data flows one way — HR to LMS: identity, job role, department, location, manager, joining and leaving dates. Learning data flows back the other way — LMS to HR: completions, scores, certificates and expiry dates. The join key is the employee ID, not the email address. Done properly, a joiner is enrolled on their correct mandatory training before their first morning, a manager sees their own team's compliance status without asking anyone, and a leaver loses access the day they leave while their training record survives for audit.
Key takeaways
- Decide which system owns which fact before you write a line of integration code. HR owns people, roles and reporting lines. The LMS owns courses, completions and scores. Anything owned by both will drift.
- The join key must be the employee ID, never the email address. Emails change on marriage, on transfer and on domain migration, and every one of those events silently orphans a learning record.
- The manager field is what makes manager reporting possible at all. Without a reliable reporting line synced from HR, there is no such thing as a manager dashboard — only an admin export that somebody forwards.
- Write-back is the half most integrations skip, and it is the half that makes the investment visible: completions and certificate expiry dates landing in the HR record, where compliance reporting already happens.
- A leaver should be deactivated, not deleted. Access ends on their last day; the training record stays as audit evidence and, if they are ever rehired, their history is still there.
- Batch sync is more stable and slightly stale. Real-time is accurate and fails everywhere at once. Most organisations should start with a nightly batch and add real-time only for joiners and leavers.
The problem this actually solves
In almost every organisation two systems hold overlapping copies of the same people. The HR system knows who works here, their job title, department, location, who they report to, and when they joined or left. The LMS knows what training those same people need, what they have started, and what they have passed.
When the two do not talk, a person keeps them aligned by hand. That person exports a spreadsheet of new joiners, creates accounts, assigns courses, chases completions, and copies certificates back into employee files. The work is invisible until it fails an audit.
And it does fail, predictably, in the same four places:
- The joiner who trained late. Someone started on the 1st, the LMS heard about them on the 12th, and their mandatory safety module was completed three weeks into a job they were already doing.
- The leaver who still has access. Offboarding removed the email and the building pass. Nobody removed the LMS account, because the LMS was not on the offboarding checklist.
- The manager who cannot see their team. Reporting lines live in HR and were never sent to the LMS, so "show me my team's compliance status" is an admin request rather than a dashboard.
- The mover nobody re-enrolled. A person transferred from warehouse to forklift operation. HR knows. The LMS still thinks they are in the warehouse, and the certification they now need was never assigned.
Integration is not primarily about convenience. It is about making the training record match reality closely enough that you can defend it.
The direction map: what flows which way
This is the part worth getting right on paper before anyone opens an API console. Every field belongs to exactly one system, and moves in exactly one direction. A field that both systems can edit is a field that will eventually disagree with itself.
HR to LMS — the outbound half
| Field | What the LMS does with it | If it is missing or wrong |
|---|---|---|
| Employee ID | The permanent join key for every record | Duplicate accounts, orphaned history, reports that undercount |
| Job role / title | Drives role-based auto-enrolment | Mandatory training is assigned by hand, or not at all |
| Department / division | Cohorts, reporting groups, curriculum scoping | Reports cannot be cut the way the business is organised |
| Location / site | Jurisdiction-specific training, language, local rules | Wrong statutory module for the state or country |
| Manager (employee ID) | Builds the reporting tree that manager dashboards need | No manager reporting exists — see the section below |
| Joining date | Starts induction clocks and due dates | Deadlines calculated from the account-creation date instead |
| Employment status / active flag | Enables and disables the account | Leavers keep access; long-leave staff get chased for overdue training |
| Cost centre | Charges training spend to the right budget | L&D cannot show where the money went |
| Preferred language | Serves the right language version | Everyone gets English, and frontline completion rates show it |
If those field names look familiar, they should: employeeNumber, costCenter, organization, division, department and manager are exactly the six attributes in the SCIM enterprise user extension. The standard was designed around this problem.
What is genuinely essential, and what is optional
You can integrate with far fewer fields than most vendors imply. The minimum that produces a working system is five:
- Employee ID — the join key. Nothing works without it.
- Full name and work email — identity and notifications. The email is for contact, not for matching.
- Job role — the thing auto-enrolment keys off.
- Manager's employee ID — the thing manager reporting keys off.
- Active status with joining and exit dates — the thing the account lifecycle keys off.
Everything else — location, cost centre, language, grade, contract type — earns its place by enabling a specific report or a specific enrolment rule. Ask what breaks if you leave it out; if nothing does, leave it out. Every extra synced field is another field that can go stale and another column in a mapping document somebody has to maintain.
The email-as-key mistake
Worth stating plainly because it is the most common and most expensive error. Using the work email as the match key feels natural — it is unique and human-readable. It is also mutable. People change surnames. Companies migrate domains. Transfers reissue addresses. Each of those events creates a new LMS user and abandons the old one, taking every completion record with it. Six months later the compliance report is quietly wrong and nobody can explain the gap. Match on the immutable employee ID and store the email as an ordinary attribute.
The five ways it gets built
These are not competing products; they are layers, and a mature integration usually uses three of them at once. Authentication, provisioning and write-back are separate problems and are normally solved by separate mechanisms.
1. SSO — SAML 2.0 or OpenID Connect
Solves logging in, and nothing else. The learner clicks a link and is already signed in. This is consistently the single largest driver of completion rates, because a separate LMS password is a wall that a meaningful share of frontline staff will simply not climb.
What it does not do: create the account, assign the course, or tell the LMS anything about the person's role. SSO with just-in-time provisioning creates a bare account on first login, which is enough for voluntary learning and not enough for compliance — you cannot report on people who have not logged in yet.
2. SCIM — the provisioning standard
Defined by RFC 7643 (the schema) and RFC 7644 (the protocol). The HR system or identity provider pushes create, update and deactivate operations to the LMS as they happen. Its enterprise user extension carries employeeNumber, costCenter, organization, division, department and manager — the exact set the previous section arrived at independently.
Use it when your HRIS or IdP already speaks SCIM and your LMS accepts it. It is the cleanest option available and it handles joiners, movers and leavers in one mechanism.
Watch for: the active attribute is a boolean whose meaning the spec leaves to the implementation. Confirm what your LMS actually does when it receives active: false — disable the login, or delete the user and their history? That single behaviour decides whether your leaver policy works.
3. Direct API integration
The HRIS API on one side, the LMS API on the other, and code in between that you own. Maximum control, maximum flexibility, and a permanent maintenance obligation: both vendors will version their APIs on their own schedule and neither will ask you first.
Use it when the mapping is genuinely bespoke — custom fields, unusual enrolment logic, an in-house HRMS with no standard interface.
4. Flat-file sync over SFTP
A scheduled CSV drop. Unfashionable, and still the right answer more often than anyone admits. It is transparent, debuggable, works with any HRIS including one nobody supports, and when it breaks you can open the file and see why.
Use it when the HRIS is old, locked down, or on-premise; when nightly freshness is enough; or as the pragmatic first phase while a proper API integration is scoped.
5. Middleware / iPaaS
An integration platform sits between the two systems and handles mapping, transformation, retries and monitoring. Buys you observability and error handling you would otherwise build, at the cost of another subscription and another system to understand.
Use it when this is not your only integration. If HR already pushes to payroll, ITSM and access control, the LMS becomes one more route on infrastructure that already exists.
Which combination to actually pick
| Situation | Sensible stack |
|---|---|
| Cloud HRIS, cloud LMS, both speak the standards | SSO + SCIM, API for write-back |
| On-prem or legacy HRMS | SSO + nightly SFTP file, API write-back if available |
| Several systems already integrated | SSO + iPaaS for everything else |
| Unusual enrolment rules nobody supports | SSO + SCIM for people, custom API for the enrolment logic |
Sync back: what the LMS returns to HR
This is the half that gets cut when a project runs late, and it is the half that makes the whole thing visible to anyone outside L&D. Provisioning saves the LMS admin time. Write-back is what puts training on the same page as the rest of the employee record.
What should flow back, per person per course:
- Completion status and date — the compliance primitive. Everything else is detail.
- Score or result, where the course is assessed and the pass mark matters.
- Certificate reference and issue date — so the certificate lives in the employee file, not in an inbox.
- Expiry or renewal-due date — the field that makes recertification automatic instead of a calendar reminder somebody owns.
- Attempts and time spent, if you have a genuine reason. Often you do not, and it becomes surveillance data nobody uses.
The expiry date is the one to insist on. Most write-back implementations send "completed on 4 March" and stop. Send the renewal date too, and the HR system can generate the "expires in 30 days" list on its own. Without it, somebody maintains that list by hand and it drifts.
xAPI and the learning record store
For fine-grained activity — not just "passed" but every interaction along the way — xAPI writes statements to a learning record store, which becomes the analytics source. This is genuinely useful when you are studying learning behaviour. It is not a substitute for completion write-back to HR: the HR record wants one authoritative fact per requirement, and an LRS holds thousands of events. Use both, for different questions.
Do not write back into fields HR owns
Write-back should populate learning fields on the employee record and nothing else. An integration that updates job titles or department names from the LMS side has broken the ownership rule from the first section, and the two systems will start correcting each other in a loop.
How manager reports actually get built
"Give managers visibility of their team's training" is on every requirements list and is usually the first thing to be quietly dropped. The reason is almost always the same: nobody synced the reporting line.
A manager dashboard is not a reporting feature. It is a data feature. It requires the LMS to know, for every learner, who their manager is — and that fact lives in HR and changes constantly. Once the manager's employee ID is synced as an attribute on each learner, the dashboard becomes straightforward: filter by manager, group by course, show status. Without it, the best you can offer is an admin who exports a spreadsheet and emails it, which is what most organisations are actually doing when they say they have manager reporting.
Direct reports or the whole tree?
Decide early. A front-line supervisor wants their eight direct reports. A department head wants every person beneath them, four levels down. Those are different queries, and the second needs the reporting chain to be walkable — each record pointing at its manager, all the way up. Build for the tree; the flat case is a special case of it.
The mover problem, which is the one that bites
Joiners and leavers get attention because they are events with a date. Movers — internal transfers, promotions, reorganisations — are where manager reporting silently rots. Someone moves team in March. If the manager field does not resync, they stay on their old manager's dashboard and are invisible on their new one. Nobody notices, because both dashboards still look plausible. Six months later a reorg reveals that a whole department has been reporting to someone who left.
Two things prevent it: sync the manager field on every run rather than only on create, and reconcile periodically — count learners whose manager ID no longer matches an active employee. That number should be zero, and when it is not, it tells you exactly which records to fix.
What managers should see, and what they should not
Compliance status, overdue items, upcoming expiries, completion dates. That is the useful set. Quiz scores, attempt counts and time-on-page are usually a mistake to expose: they invite performance conversations the data cannot support, and they make learners defensive about a system that is supposed to be safe to fail in. Give managers what they need to act, not everything the LMS happens to record.
When somebody leaves: the part everyone gets wrong
The instinct is to delete the account. It is the wrong instinct, and acting on it destroys evidence you are usually required to keep.
Three separate things happen at exit, and conflating them is the whole problem:
- Access must end. Immediately, on the last working day. This is a security matter and it is the part that most often does not happen, because the LMS is not on the offboarding checklist.
- The training record must survive. If a former employee's statutory training is questioned — an incident, an inspection, a dispute months later — "we deleted it when they left" is not an answer. The record is evidence that a duty was discharged at the time.
- Personal data is subject to retention limits. It cannot be kept indefinitely just because it is convenient.
Deactivate, do not delete
The correct pattern is a soft deactivation: the account is disabled, the login stops working, the person disappears from active dashboards and overdue reports — and the completion history remains attached to the employee ID. In SCIM terms this is active: false, not a DELETE.
Confirm what your LMS actually does on receiving that, because the standard leaves the behaviour to the implementation. Some platforms disable. Some delete the user and cascade the deletion through the enrolment records. Test it with a throwaway account before you trust it with a real one.
Rehires, which are more common than you think
A deleted leaver who returns eighteen months later comes back as a brand-new person with no training history, and repeats every mandatory module they already passed. A deactivated one is reactivated against the same employee ID, with their record intact and only genuinely expired certifications to redo. In sectors with seasonal or project-based hiring this alone justifies the pattern.
Retention, and where it meets Indian data protection law
Retaining a training record is not a licence to retain everything forever. The defensible position is to define a retention period per category — driven by the statutory or contractual requirement behind the training, not by what is easiest — and then reduce the record at the end of it rather than keeping it whole.
Practically that usually means keeping the fact and dropping the person: after the retention period, the completion, date and certificate ID are retained in anonymised or aggregate form, while the identifying personal data is removed. You keep the ability to show that a role was trained; you stop holding a named individual's data past its purpose.
India's DPDP Rules make this concrete, and the substantive obligations — including erasure and retention duties — sit in the phase commencing around May 2027. That is enough runway to design the policy now rather than retrofit it. Our guide to what the DPDP Rules say and when they apply covers the timing and the obligations; this is general information rather than legal advice, and your retention periods should be set with your own counsel.
- 1Write the ownership table before anything else
One row per field, one column saying which system owns it and which direction it moves. Get HR and L&D to sign it. Every argument you would otherwise have in month three happens here instead, on paper, cheaply.
- 2Fix the employee ID in the HRIS first
If IDs are missing, duplicated or reused, the integration will faithfully reproduce that mess at scale. Clean the source. Integrations replicate data quality problems, they do not solve them.
- 3Ship SSO on its own, before any provisioning
It is the smallest piece with the largest visible effect, it proves the identity plumbing works, and adoption improves immediately — which buys goodwill for the rest of the project.
- 4Provision one department, in read-only dry run
Generate what would be created, changed and deactivated, and have HR eyeball it. The dry run always finds something: a contractor population nobody mentioned, a department name that differs by a space.
- 5Turn on joiners and leavers before movers and enrolment rules
Those two events carry the security risk and the audit risk. Get them reliable, then add role-based auto-enrolment once you trust the people data underneath it.
- 6Build write-back in the same project, not the next one
Completion, date, certificate reference and expiry. Deferred to phase two, it does not happen, and the integration stays invisible to everyone except the LMS admin.
- 7Add reconciliation and alerting, then leave it alone
A daily job that counts records the two systems disagree on, and a channel it shouts into when the number is not zero. A silent integration is not a working one — it is an unmonitored one.
Nightly batch sync
- Predictable, debuggable, and easy to re-run when something fails
- One clear window to investigate — you know exactly what changed and when
- A joiner created after the run waits until tomorrow to get access
- A leaver keeps access until the next run, which may be unacceptable on its own
- Right for most organisations as the starting point
Real-time / event-driven
- A change in HR appears in the LMS within seconds
- Leaver access ends at the moment of the HR transaction, which is the security answer
- Bad data propagates just as fast as good data, with no window to catch it
- Needs retry handling, dead-letter queues and monitoring you must actually build
- Right for joiner and leaver events specifically, even if everything else stays batch
Need something custom-built?
We build and run this end to end — SSO, provisioning, role-based enrolment, completion write-back and the reconciliation job that tells you when it drifts — across cloud HRIS platforms and in-house HRMS alike. If your LMS is Moodle, the mechanics are covered in detail in the Moodle-specific guide linked at the end. edzlms adds two layers on top: EDZLMS AI to build the learning path per role rather than a fixed checklist, and Gelato for scored conversational practice where the training needs to change behaviour, not just record attendance.
Test your leaver policy with a throwaway account before you trust it.
Create a test user, enrol them, complete a course, then send the deactivation your integration will actually send. Now look: is the login disabled and the completion history intact, or did the user and their records disappear together? Ten minutes of work, and it is the single assumption most likely to be wrong in a way you will not discover until an audit.
Frequently asked questions
What is HRMS–LMS integration?
A connection that makes the HR system the authoritative source for people data and the LMS the authoritative source for learning data, then keeps them in agreement automatically. People data — identity, role, department, manager, joining and exit dates — flows from HR to the LMS. Learning data — completions, scores, certificates and expiry dates — flows back. The two halves are separate pieces of work and are usually built by different mechanisms.
Which data fields are essential?
Five: employee ID as the join key, name and work email, job role for auto-enrolment, the manager's employee ID for manager reporting, and active status with joining and exit dates for the account lifecycle. Everything else — location, cost centre, language, grade — should earn its place by enabling a specific report or enrolment rule.
Why not match users on email address?
Because emails change. Surnames change on marriage, transfers reissue addresses, and companies migrate domains. Each of those creates a new LMS user and abandons the old one along with its completion history. Match on the immutable employee ID and hold the email as an ordinary attribute.
How do managers get reports on their team?
By syncing the manager's employee ID onto every learner record. That single field is what makes a manager dashboard possible — filter by manager, group by course, show status. Without it you do not have manager reporting, you have an admin who exports a spreadsheet. Decide early whether managers see direct reports only or the whole tree beneath them, and build for the tree.
What happens when an employee leaves?
Three separate things, and conflating them is the common mistake. Access must end immediately. The training record must survive as evidence that a duty was discharged. And the personal data is still subject to retention limits. The pattern that satisfies all three is soft deactivation — disable the login, keep the completion history against the employee ID — followed by reducing the record to anonymised form at the end of a defined retention period.
Should we delete a leaver's LMS account?
No. Deleting destroys audit evidence you may be required to produce, and it means a rehire returns as a brand-new person who must repeat every module they already passed. Deactivate instead. Confirm what your LMS actually does on deactivation, because some platforms cascade a delete through the enrolment records — test it with a throwaway account.
Real-time sync or nightly batch?
Start with nightly batch for everything, because it is predictable and debuggable, then move joiner and leaver events to real-time. Those two carry the security and audit risk and genuinely need to be immediate. Real-time everywhere is accurate and fragile — bad data propagates as fast as good data, with no window to catch it.
Do we need SCIM, or is an API integration enough?
SCIM is the cleanest option when both sides already speak it — it is defined by RFC 7643 and 7644 and handles joiners, movers and leavers in one mechanism, with an enterprise extension carrying exactly the fields this problem needs. A direct API integration gives more control and costs a permanent maintenance obligation as both vendors version their APIs. A scheduled SFTP file remains a legitimate answer for a legacy or locked-down HRIS.
Where to start
The first useful step costs nothing and needs no vendor: write the ownership table. One row per field, one column for which system owns it, one for which direction it moves. It takes an afternoon with HR and L&D in the same room, and it converts an abstract integration project into a specific list of decisions — most of which are business decisions rather than technical ones.
Related reading:
- Integrating Moodle with HR software — the same problem solved specifically on Moodle: SSO plugins, web services, and the provisioning options that platform gives you
- LMS–SIS integration for universities — the equivalent problem in higher education, where the student information system plays the HRIS role
- DPDP for LMS and edtech — the retention and erasure obligations behind the leaver section, and when they commence
- SCORM vs xAPI — relevant once write-back and learning analytics enter scope
If you want the ownership table reviewed by someone who has built this before, or a straight answer on whether your current HRIS and LMS can talk at all, we will look at it with you.
Or write to marketing@edzlms.com.