Docebo Connect recipes: fundamentals, lifecycle, and design patterns

For a Spanish SME running Docebo as the LMS — typically with 50-200 learners, an HRIS pushing employee records nightly, and a single integration owner who is the L&D lead with a technical background rather than a dedicated engineer — the recipe is the unit of work that turns “we have an LMS” into “we have an LMS connected to the systems our business actually runs on.” A recipe in Docebo Connect is a Workato-runtime workflow with one trigger and one or more steps, and the operational difference between an SME that uses recipes well and one that does not is roughly the difference between 4 hours of integration maintenance per month and 4 hours per week. The vocabulary is small. The patterns are predictable. The discipline is in knowing when each pattern fits and when it does not.

Recipe vocabulary — the four concepts the SME’s integration owner should learn first

Every recipe runs against a small set of concepts that recur across every integration the SME builds. Learning the four below means the SME’s integration owner can read any recipe in the catalogue and predict where to look when something fails.

The workspace is the top-level unit. Every Docebo Connect customer gets one workspace per Docebo tenant, and the workspace contains everything the recipes need to run — the recipes themselves, the connections to external systems, the lookup tables, and the job history. The sandbox tenant gets its own workspace, which is the surface where every change should be tested before it reaches production.

The project or folder is the organisational layer. The SME’s integration owner should keep custom recipes — anything the SME has authored or modified — in projects under the SME’s control, and never directly in the special Docebo-maintained folders that auto-update with platform releases. The auto-update is the silent failure mode: an integration owner who customises a recipe inside a Docebo-maintained folder will lose those customisations the next time Docebo releases an update, with no warning.

The connection is the credential layer. A connection is an authenticated link to an external system — Workday, HiBob, Microsoft 365, Credly. The connection holds the OAuth token, the API key, the service-account credentials, and the recipe references the connection by name. The discipline is one connection per external system, named for what it is (hibob_prod, not hibob_jane_personal_account), shared across all recipes that talk to the same system.

The job is the execution unit. Each time a recipe fires — whether scheduled at 2 AM Madrid time or webhook-triggered by an external event — it produces one job with a unique ID, full input/output logging, and a per-step trace of what happened. The job log is the audit artifact a Spanish SME under INCIBE supply-chain expectations should be able to point to when asked “what did your integration do at 03:14 last Tuesday.”

Recipe lifecycle and trigger types — what state means and when each trigger fits

A recipe lives in one of four lifecycle states, and the integration owner should know which state means what.

Draft is the recipe being built or edited. Draft recipes cannot process events — the trigger is not subscribed and no jobs run. Testing is the state where the recipe runs in test mode, making real API calls against the connected systems. The discipline is to test against sandbox connections rather than production, because test-mode jobs in production will move real data. Active (Started) is the live state — the recipe is processing events as they occur. Stopped is the paused state — the recipe is configured but not running. The pattern the integration owner runs is Draft → Testing (against sandbox) → Active (in production), with Stopped used as the kill switch when something is misbehaving and the team needs the recipe quiet while they investigate.

The trigger is the recipe’s starting point and the SME’s integration owner picks one of two categories. Polling triggers periodically query an external application to check for new events or data — the recipe runs on a fixed cadence (every 15 minutes, hourly, daily) and asks the source system “what is new since I last asked.” Polling is the right answer when the source system does not support webhooks, when latency is not critical (the SME does not need real-time provisioning), and when the operational simplicity of a fixed cadence is worth the latency cost. Event-driven triggers subscribe to a source-system event — user enrollment, course completion, assignment update — and the recipe fires the moment the event happens. Event-driven is the right answer when latency matters (a new hire needs to start training on day one), when the source system supports webhooks reliably, and when the SME has the operational maturity to monitor a webhook endpoint.

For a Spanish SME under EU AI Act Article 13 transparency expectations on AI-augmented workflows, the documented choice between polling and event-driven for each recipe — with the reasoning behind it — is itself part of the audit surface.

Recipe design patterns — synchronous, asynchronous, and the operational trade

The 30+ pre-built recipes in the Docebo Connect catalogue cluster into a small set of design patterns the SME’s integration owner should know by name. Two cover most of what the SME will build.

Synchronous integration is the pattern where the recipe waits for the downstream system to respond before completing. The trigger fires, the recipe calls the downstream API, the recipe receives the response, the recipe completes. Synchronous is right when the operation is fast (sub-second), the response matters to the recipe’s logic (the recipe needs the new user’s ID to use in a follow-up step), and the consequence of a slow downstream is acceptable (a few seconds of latency is fine). Synchronous is wrong when the downstream is slow (multi-second responses), when the recipe needs to fire frequently (the synchronous wait stacks up), or when downstream failures should not block the recipe’s other work.

Asynchronous processing is the inverse — the recipe fires the downstream operation, does not wait for the response, and continues. The downstream system processes the work on its own schedule and either reports back via webhook or the SME polls for completion separately. Asynchronous is right when the operation is slow (bulk imports, large file processing), when the recipe needs to fire frequently (parallel processing scales better), or when downstream failures should not block the recipe’s other work. The cost is operational complexity — the SME needs to track whether the downstream operation actually completed.

The patterns map to the SME’s typical recipe catalogue: User Sync (synchronous, one user at a time), Calendar Sync (synchronous, one event at a time), Badge Issuance (synchronous, one credential at a time), Bulk Import (asynchronous, many records at a time). 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 — three or four foundational recipes are the deliverable that converts “we deployed an LMS” into “we deployed an LMS that talks to four other systems with documented patterns.” The official recipe references live 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.