Docebo Connect Data Tables vs Lookup Tables: when each fits

For a Spanish SME running Docebo as the LMS with a recipe catalogue that has grown past three or four integrations, the question of where state lives between recipe executions is the next operational decision the integration owner makes. State is the data the recipes need to remember from one run to the next — the queue of records that failed and need retry, the running count of completions per branch this month, the deduplication tracker that prevents the same enrollment from being created twice, the audit log of every credential issued with timestamp and recipient. Without a place to put that state, the SME ends up either spinning up a side database that adds infrastructure complexity, or skipping the state altogether and accepting the operational cost of duplicates and missing audit trails. Docebo Connect’s built-in Data Tables and Lookup Tables are the answer for both — but they solve different problems and the integration owner should know which fits which use case.

Data Tables vs Lookup Tables — the difference that determines which to use

The two table types are easy to confuse because both store structured records inside the Docebo Connect workspace and both are queryable from recipe steps. The operational difference is what each is built to do.

Data Tables are the right answer when the recipe needs to write — a failed-record queue that the recipe creates, reads, and clears; a job-execution metric that increments on every recipe run; a deduplication tracker that the recipe checks before creating a new enrollment and updates after the create succeeds. The defining property is that the table’s contents change as a result of recipe execution.

Lookup Tables are the right answer when the recipe only needs to read — a mapping from external HRIS department codes to Docebo branch IDs that the SME’s L&D team maintains by hand; a list of country codes to default-language assignments; a translation table from Workday job-family codes to Docebo learning-plan IDs. The defining property is that the table’s contents are stable, maintained by a human, and consulted (not modified) by the recipes.

The mistake the SME’s integration owner should not make is using Data Tables for what should be Lookup Tables. Putting a 50-row department-to-branch mapping into a Data Table works, but the cost is operational confusion later — the L&D lead does not know whether to update the table directly or wait for a recipe to update it, and the audit trail conflates “human edited the mapping” with “recipe wrote a row.” The reverse mistake — using Lookup Tables for state that recipes need to mutate — fails outright because Lookup Tables do not support recipe writes.

When to use Data Tables — the patterns that justify the persistence layer

Data Tables earn their place in the SME’s recipe catalogue when one of a small set of patterns is in play. The integration owner should learn the patterns by name, because each one shapes the table’s schema differently.

Failed-record queues are the most common pattern. A recipe attempts an operation against an external system (create a Docebo user, post a credential to Credly, send a notification to Microsoft Teams), the operation fails because the external system is down or the data is malformed, and rather than dropping the failure on the floor the recipe writes the failed record to a Data Table for later retry. A second recipe — the retry recipe — runs on a scheduled cadence, reads the failed-record queue, attempts each operation again, and removes the row on success or increments a retry counter on continued failure. The pattern keeps the SME’s main recipes simple (they don’t have retry logic baked in) and isolates the failure-handling concern in one auditable place.

Recipe execution metrics are the second pattern. The recipe writes a row each time it runs — timestamp, recipe name, success/failure flag, records processed, errors encountered. Over time the table accumulates an operational dashboard the integration owner can query: how many User Sync runs succeeded last week, what was the average processing time, which recipes are silently failing. For a Spanish SME under INCIBE supply-chain expectations, the metrics table is the documentation surface that turns “we have integrations” into “we monitor our integrations and have evidence.”

Deduplication trackers are the third pattern. Before creating a new record in the destination system, the recipe checks the dedup table to see if an equivalent record was already created in a recent window. The pattern prevents the duplicate-user-creation failure mode that haunts SMEs whose HRIS occasionally fires the same employee-created event twice (a known idiosyncrasy of certain HRIS platforms during weekend batch processing).

Audit trails are the fourth pattern. Every credential issued, every enrollment created, every deactivation processed gets a row in an audit Data Table — with the actor (the recipe name), the action (issue/create/deactivate), the subject (the learner ID), the timestamp, and the result. The audit trail is the artifact a Spanish SME under EU AI Act Article 13 transparency expectations on AI-augmented training workflows can point to when asked who did what when.

Best practices and operational discipline — what an SME should and should not put in Data Tables

Data Tables are not a general-purpose database. The SME’s integration owner should be deliberate about what belongs in a Data Table and what belongs elsewhere.

Do use Data Tables for intermediate state between recipes — failed records waiting for retry, deduplication windows, execution metrics, audit logs. The volume is bounded (10s to 10,000s of rows), the access pattern is predictable (recipes write and read on a known cadence), and the data is operational rather than business-critical.

Do not use Data Tables for bulk user records or to replace the source system’s data. The Data Table is not the system of record for “who is an employee” — that is the SME’s HRIS, and copying the HRIS contents into a Data Table creates a second source of truth that will drift. The Data Table is also not a replacement for the SME’s data warehouse — large-volume analytical queries against Data Tables will be slow and expensive compared to the same queries against a proper warehouse.

Performance considerations matter once the table grows past about 50,000 rows. Indexed columns are fast to query; non-indexed columns require a table scan that gets slower as the row count grows. The integration owner should design the schema with indexes on the columns the recipes will filter by — typically a status column for failed-record queues, a timestamp column for audit trails, a record-key column for deduplication trackers.

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 documented Data Table schemas, the per-recipe access patterns, and the retention policy (how long failed-record queue rows survive before cleanup) are deliverables that convert “we use Data Tables” into “we use Data Tables with documented governance.” The official Data Tables 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.