Identity sync is stage 1 of the 5-stage HRIS-L&D integration. Build it correctly and the other four stages have a foundation. Build it sloppily and every downstream stage inherits the problem.

Before you start

Confirm three prerequisites. First, both HRIS and L&D expose the required APIs (employee read, employee webhook on HRIS side; learner upsert on L&D side). Second, both sides agree on employee ID as the join key. Third, an orchestration layer exists — Make.com is the recommended platform when neither vendor ships a native connector. Read the HRIS + L&D API Integration — Complete 2026 Guide for the architecture context.

Step 1 — Map the employee record schema

Build a written contract that lists every field flowing from HRIS to L&D. The minimum set is employee ID, work email, first name, last name, hire date, manager ID, department, job title, employment status. Each field has a source-of-truth designation (HRIS owns this field) and a default rule when the source is empty (skip vs send empty vs send null). The contract is reviewed by HRIS admin and L&D admin before build starts.

Step 2 — Stand up the webhook receiver

Create a Make.com scenario triggered by the HRIS employee webhook. The webhook URL is registered on the HRIS side; HRIS posts a payload to the URL on every employee create, update, and termination. The scenario validates the payload against the contract from Step 1 and rejects malformed payloads to an error queue rather than processing them.

Step 3 — Implement the upsert call

Add a module that calls the L&D learner upsert API with the mapped fields. Use HTTP POST with the sent_from (Make scenario URL) and sent_to (L&D endpoint) fields in the body for traceability. The upsert is keyed on employee ID — if the learner exists, the call updates; if not, the call creates.

Step 4 — Wrap the call in the error handler

Attach a builtin:Break error handler with 3 retry attempts at 60-second intervals. The error handler logs each retry and notifies an operations channel if all three retries fail. The 60-second interval handles transient L&D rate-limit and network errors without operator intervention.

Step 5 — Add the reconciliation job

Build a separate Make.com scenario that runs daily at 02:00 local time. The scenario pulls the full employee list from HRIS, pulls the full learner list from L&D, joins on employee ID, and reports any employee-without-learner or learner-without-employee record to an HRIS admin queue. Reconciliation runs continuously and surfaces drift within 24 hours.

Step 6 — Validate with a parallel run

Before cutover, run the new identity sync in parallel with the existing process (whatever that was — CSV upload, vendor SFTP, manual spreadsheet) for two weeks. Reconcile the two output sets daily. When the new sync matches the legacy process on every record for five consecutive business days, cut over and retire the legacy process. The 10 patterns guide covers the durability patterns the identity sync needs to inherit.

FAQ

What if HRIS does not expose an employee webhook?

Fall back to polled read every 5 minutes against a last-modified filter. Latency increases but the integration still works. The 7 essential APIs guide covers fallback options.

How do you handle duplicate employee records?

Flag duplicates for HRIS-side resolution rather than auto-merging. Auto-merge produces unauditable data; manual resolution preserves the audit trail.

What is a realistic build duration for identity sync?

10 to 15 business days for an experienced build team, including the two-week parallel-run validation.