Docebo External IDs Connector: identity mapping for Spanish SMEs
For a Spanish SME running Docebo as the LMS — typically 50-200 employees, a single integration owner who is the L&D lead with a technical background, and a multi-system landscape that includes an HRIS, an identity provider, a credentialing platform, and one or two other LMS or content platforms inherited from previous tooling decisions — the question of “is the user in Workday the same person as the user in Docebo and the same person as the recipient in Credly” is the operational question that decides whether the integration catalogue is trustworthy or chaotic. The External IDs Connector is Docebo Connect’s answer to that question. It is the layer that links Docebo user IDs to the equivalent IDs in every external system the SME runs, and it is the artifact every recipe in the catalogue depends on once the SME has more than one place where users live.
What the External IDs Connector is — and what it solves
The External IDs Connector is a Docebo Connect component that maintains a per-user mapping table between Docebo’s internal user ID and the user’s identifier in every external system the SME has integrated. The connector subscribes to Docebo’s event bus, listens for user lifecycle events, and updates the mapping table in real time as users are created, updated, merged, or deleted. The integration owner does not write the mapping logic — the connector handles it — but the integration owner does configure which external systems the connector knows about and which event types it should react to.
The five key benefits the connector delivers are predictable enough that the SME’s integration owner should learn them by name.
Cross-Platform Identity Mapping is the headline benefit — every recipe in the catalogue can ask “what is this Docebo user’s ID in Workday” or “what is this Workday user’s ID in Docebo” and get a deterministic answer. Without the connector, every recipe has to maintain its own mapping logic, which means duplicated code, inconsistent behaviour across recipes, and bugs that surface only when users are renamed or merged.
Duplicate Prevention is the second benefit. When the recipe is about to create a new Docebo user from an HRIS event, it first asks the connector “does a Docebo user already exist for this Workday employee ID” — if the answer is yes, the recipe updates the existing user instead of creating a duplicate. The pattern eliminates the duplicate-user-creation failure mode that haunts SMEs whose HRIS occasionally fires the same employee-created event twice.
ID Lookup is the operational convenience. The integration owner running an investigation against an audit query (“who got assigned this learning plan last week”) can use the connector to translate Docebo user IDs back to HRIS employee codes that the L&D lead and the HR business partner can both recognise.
Bidirectional Reconciliation is the periodic-correction benefit. The connector can run scheduled reconciliation jobs that walk both directions of the mapping (Docebo→external, external→Docebo) and surface inconsistencies — orphan mappings, missing users, duplicates that survived. The reconciliation report is the artifact the SME’s integration owner reviews monthly to catch drift before it becomes an incident.
Audit Trail is the compliance benefit. Every mapping change — create, update, delete — is logged with timestamp, source event, and actor. For a Spanish SME under INCIBE supply-chain expectations on documented integration governance, the audit trail is the documentation surface that proves the SME knows how its users are reconciled across the systems boundary.
Event subscriptions — what the connector listens to
The connector’s real-time mapping behaviour depends on subscribing to the right events on the Docebo event bus. The integration owner should know which event types matter and what the connector does when each fires.
| Event category | Event types | Connector action |
|---|---|---|
| User Events | Created, Updated, Self-Registration Approved, Deleted | Add, refresh, or remove mapping rows |
| Branch Events | Branch Added, Branch Removed | Update org-affiliation context for affected mappings |
| Course Events | Course Created, Course Updated, Course Deleted | Refresh course-side mapping references |
| ILT Session Events | Session Created, Session Updated, Session Cancelled | Refresh session-side mapping references |
User Events are the core. Created fires when a new Docebo user is provisioned (via HRIS push, self-registration, or admin creation), and the connector adds a new mapping row linking the Docebo ID to the corresponding external ID if the source system event provides one. Updated fires when user attributes change, and the connector refreshes the mapping if the external ID changed. Self-Registration Approved fires when a self-registered user is approved by an admin, and the connector adds the mapping. Deleted fires when a user is deactivated or removed, and the connector marks the mapping as inactive (rather than hard-deleting, to preserve the audit trail).
Branch Events matter because branches in Docebo correspond to organisational units (departments, regions, business units) in the SME’s HRIS. When a branch is added or removed, mappings affected by the branch change need to be refreshed so downstream recipes (department-based learning-plan assignment, region-based reporting) continue to behave correctly.
Course Events and ILT Session Events are the content-side mapping. The connector tracks which Docebo courses correspond to which external content references (a Workday learning item, a Credly badge template, a Microsoft Teams calendar template), and the events trigger refreshes when the underlying content changes.
For a Spanish SME under EU AI Act Article 13 transparency expectations on AI-augmented training workflows that touch identity, the documented event-subscription configuration — which events are subscribed, why, and what the downstream behaviour is — is itself part of the audit surface.
Configuration discipline and the operational rhythm
The External IDs Connector is configured once and then maintained on a quiet rhythm. The configuration step takes 1-2 hours for a new external system — the integration owner adds the system to the connector’s configuration, defines the field mapping (which Docebo user attribute corresponds to which external system field), enables the relevant event subscriptions, and runs an initial reconciliation to populate the mapping table from existing users. The maintenance rhythm is 30 minutes per month — the integration owner reviews the reconciliation report, investigates any inconsistencies, and approves any auto-resolutions the connector has proposed.
The discipline that converts the connector from a one-time setup into a sustainable operational artifact is documenting the field mapping for each external system. The SME’s integration owner should keep a one-page note per external system covering: which Docebo attribute is the external ID source, which external system field is the mapping target, what the format constraints are (UUID, integer, email-like string), and what the fallback is when the external system does not provide an ID for a new user.
For a Spanish SME accessing Kit Digital IA/BI vouchers — Segment III (10-50 employees) up to €12,000, Segment II (3-9 employees) up to €6,000 — the configured External IDs Connector with documented field mappings, monthly reconciliation cadence, and ENS-aligned audit trail is the deliverable that converts “we have integrations across systems” into “we have integrations with documented identity governance.” The Agente Digitalizador can install the connector, configure the mappings for the SME’s two or three external systems, set up the reconciliation cadence, and hand the L&D lead a workspace that catches identity drift before it becomes an incident. The official External IDs Connector reference lives at help.docebo.com and the broader product context at docebo.com.
Ready to get started?
Working on this yourself? J4SGON S.L. delivers Docebo Connect, HRIS, SSO and migration work for European organisations — see what a scoped engagement covers or describe your project and we will reply with a written scope.
Tell us what you are integrating or migrating
Send the platform, the systems involved and where you are stuck. You get a written scope back — phases, deliverables and what is out of scope — before anything is billed.