Docebo Connect recipes: the SME integration guide
For a European SME running Docebo as its learning platform, the integration question is almost always the same: how do we keep Docebo in sync with the HR system of record without a person copying user lists between them? Docebo Connect recipes are the answer — automated workflows that fire on triggers from one system, take actions against another, and remove the manual data entry that breaks when someone goes on holiday. This guide walks through what a recipe actually is, the three recipe types, how to build one, and the GDPR posture every SME needs to set up alongside the technical work.
What a Docebo Connect recipe is
A recipe is a named automation that couples one trigger to one or more actions. The trigger is an event in a source system — “user created in Workday”, “course marked completed in Docebo”, “new hire record in BambooHR”. The action is the follow-on step in the target system — “create user in Docebo”, “enrol in onboarding course”, “post notification to Slack”. Between the two, a recipe may check conditions, transform fields, and branch execution paths.
The operational logic is straightforward: the trigger fires, the recipe evaluates any conditions attached, and if the conditions are met the actions execute in order. If a condition fails, the recipe short-circuits to its error handler. If an action fails partway through, the recipe logs the failure and leaves later actions unexecuted — no silent partial writes. For an SME that has been running user provisioning by hand, this is the change that turns a weekly chore into an invisible background job. Official reference material sits on help.docebo.com, which is where the supported connector list and action schemas live.
The three recipe types — and when each one fits
Docebo Connect recipes split cleanly into three execution shapes:
| Recipe type | Fires when | SME use case |
|---|---|---|
| Event-triggered | An external event arrives (webhook / polling) | New-hire provisioning, course-completion callbacks |
| Scheduled | On a cron-like calendar | Daily user deltas, weekly manager reports |
| On-demand | Manual “Test recipe” or API call | One-off imports, data migrations, debugging |
Event-triggered recipes are the real-time workhorse. A new employee lands in the HR system, a webhook fires, and within seconds the employee has a Docebo account and is enrolled in the onboarding course. For a Spanish SME inside Segment II of Kit Digital (3–9 employees, €6,000 voucher), the IA/BI category budget can fund the initial recipe build if the SME has an AI-augmented dimension to the automation — for example, a recipe that adds a RAG-driven personal-learning-path generator on top of the base provisioning flow.
Scheduled recipes are the right tool when the source system does not publish webhooks — a common reality with older HR tools — or when the volume is low enough that a nightly batch is indistinguishable from real-time for the SME’s users. Daily at 02:00 Europe/Madrid, the recipe pulls the last 24 hours of HR changes and applies them to Docebo.
On-demand recipes are the testing and migration lane. A one-time migration of 400 historical users from a legacy LMS runs as an on-demand recipe with careful dry-run output before it writes. The same recipe stays in the project folder for future re-runs — good discipline is to treat it as a named, documented procedure, not a disposable script.
Building a new recipe — the minimum viable flow
The end-to-end flow inside Docebo Connect is tight enough to describe in steps:
- Open the project folder. In Docebo Connect, navigate to Projects and select (or create) the folder that owns this integration. Keep one project per business domain — HR-provisioning in one, commerce-sync in another.
- Create a named recipe. The name is the documentation — “Workday → Docebo user provisioning (event-triggered)” beats “Recipe 3” by a factor of ten when someone else debugs it two years later.
- Pick the trigger. Choose the connection to the source system (a Workday connector, a BambooHR connector, an HTTP webhook endpoint). Configure authentication using a service account, never a personal credential.
- Define field mapping. Map the fields the source system emits to the fields the Docebo action expects. Unmapped fields do not migrate — catch this at build time, not at the first production failure.
- Add conditions. Skip test-user accounts, skip records outside your tenant, skip contractors if contractors don’t get accounts. The condition block is where you encode the SME’s actual policy.
- Add actions. Start with one. Get it green on a test user. Then add the second and third.
- Test on the on-demand path. Fire the recipe against a known sandbox payload and read the execution log end-to-end.
- Switch the trigger to live once the dry-run is clean.
The discipline that separates a recipe that lasts from one that rots is naming, versioning the mapping logic inside the recipe, and keeping a change log in the recipe’s description field. The recipe is code even if the UI is a flowchart — treat it that way.
GDPR and Article 30 — the compliance layer every recipe crosses
The technical build is half the work. The other half is the data-protection posture that a cross-system automation forces the SME to name.
Docebo Connect recipes move personal data — names, emails, employee IDs, sometimes role and department — between controllers and processors. For a Spanish SME running Docebo, the compliance checklist per recipe is:
- Controller/processor mapping. Docebo Inc. acts as processor for the SME as controller; a GDPR Article 28 processor agreement has to be in place before production data flows. Docebo’s commercial paperwork covers this; the SME’s legal function has to read and sign it, not assume.
- Article 30 record of processing. Each recipe is a processing activity; the RoPA entry names the categories of data, the lawful basis (usually Article 6(1)(b) contract — employment — or 6(1)(f) legitimate interest for training administration), the recipients, and the retention.
- Data minimisation. Map only the fields the recipe needs. A recipe that syncs full employee records because it was easier at build time is a GDPR problem waiting to surface in a data-subject access request.
- Cross-border transfers. If the Docebo tenant is hosted outside the EEA, Chapter V compliance (SCCs, TIA) applies. Check the tenant region before designing the recipe; a J4SGON edge-AI augmentation typically keeps any AI enrichment local, so the personal data does not cross a border that the LMS sync itself would not already cross.
For the broader EU AI Act context when a recipe includes AI-driven decisioning (auto-assigning learning paths, AI-generated summaries, emotion-analytic feedback), the supervisory reference is AESIA at aesia.gob.es and the consolidated Act text at artificialintelligenceact.eu. A recipe that merely moves records between systems is not a high-risk AI system; a recipe that automates employment decisions based on model output may be. The decision is worth documenting when the recipe is built, not after.
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.