Docebo Connect user anonymization: a GDPR playbook for SMEs
The GDPR right to erasure is not a one-off engineering task — it is a recurring obligation that becomes expensive the first time an ex-employee, ex-contractor, or former learner asks for their data to be deleted and your LMS admin has to go looking for it. For a Spanish SME with an active Docebo instance, the Connect user-anonymization recipe automates the process so erasure requests resolve in hours, not days, without breaking the learning records auditors still need to see.
What user anonymization actually does
User anonymization is different from user deletion. Deleting a learner in Docebo removes their entire record, which also wipes the course-completion history attached to it — and that history is frequently the evidence you need to prove compliance training was delivered on a specific date to a specific person, for audits, insurance, or labour disputes.
Anonymization preserves the training record while erasing the identity behind it:
- PII fields are overwritten. First name, last name, email, phone, and any custom identity fields are replaced with pseudonyms such as
user_4821or left blank. - Historical completions stay intact. Course IDs, completion timestamps, scores, and certificates remain on the (now anonymous) record, so your audit trail does not develop holes.
- Logins are disabled. The account is deactivated so no one can access the pseudonymised profile.
- A new record is not created. Crucially, the anonymised user is not re-created as a new learner, which would split audit histories across two rows.
The net effect is that the SME keeps the evidence it needs for compliance audits (ISO 27001, ENS, sectoral rules) while fulfilling the individual’s Art. 17 erasure request.
How the Docebo Connect recipe is wired
The Connect recipe is built around four linked steps, each of which corresponds to a node in the workflow you configure inside Docebo Connect’s recipe editor.
- Scheduled check. A cron-style trigger fires on a cadence you set — daily is standard. The schedule drives the entire workflow; erasure is not event-driven in this recipe because it is intended to run retention-based batches rather than respond to individual tickets.
- Lookup eligible users. A query reads from a lookup table (a Docebo data table or an external CSV in S3) and returns the users whose retention window has expired. The eligibility rule is written as a Ruby expression in Connect — most SMEs start with something like “last activity older than 36 months AND status = inactive”.
- Anonymise PII. For each eligible row, Connect calls the Docebo API to overwrite the mapped PII fields. Custom fields are handled the same way — any field you declared as personal data in the DPIA should be in this mapping list.
- Preserve learning records. The recipe explicitly does not touch the
enrollments,completions, orcertificateentities. An audit entry is written to the lookup table so you can demonstrate, per learner, when anonymisation ran and against which field list.
Prerequisites before you enable it
An SME-grade deployment needs four things lined up before the first production run.
Docebo side
- Docebo Connect activated on your plan (same prerequisite as every Connect recipe).
- Superadmin access to Connect’s recipe workspace.
- A dedicated project folder for the anonymisation recipe; do not clone into the example folder.
- An API key with
users: writescope.
Process side
- A written retention policy that names the trigger (inactivity window, end-of-contract + N months, etc.) and the field list. Without this, the recipe is running a policy you cannot defend on audit day.
- A signed DPIA (Data Protection Impact Assessment) covering the change. For Spanish SMEs, the AEPD guidance on pseudonymisation is the canonical reference.
- A test cohort — at minimum 3 synthetic learners and 1 real inactive learner with written consent — so the first run is observable.
Where Spanish and EU regulation lands
For SMEs under Spanish jurisdiction, anonymisation intersects with three active regulatory regimes. The shortest summary:
| Regime | What it expects | Practical check |
|---|---|---|
| GDPR (EU) | Erasure on request, retention limits, Art. 30 RoPA | DPIA + retention policy signed |
| ENS (Esquema Nacional de Seguridad) | Traceability and audit integrity | Anonymisation log in lookup table |
| EU AI Act | Transparency for high-risk systems | Declare LMS scope to AESIA if training is tied to promotions |
Funding is available for SMEs retrofitting this kind of compliance work: the Kit Digital scheme currently offers vouchers up to €12,000 for process and employee management tooling, and an anonymisation recipe build generally fits inside the “digitalización de procesos” lot. For regulatory grounding on the AI Act side, the official EU AI Act portal is the authoritative public reference.
A realistic build-and-rollout timeline
| Phase | Duration | What happens |
|---|---|---|
| Policy + DPIA | 3–5 days | Write retention rule, sign DPIA, map PII fields. |
| Lookup table + API key | 1–2 days | Create the data table, scope the API key, test read access. |
| Recipe build | 3–5 days | Wire the four nodes in a dedicated folder, add error handling. |
| Dry run on synthetic cohort | 2–3 days | Run against 3 synthetic learners, verify completions persist. |
| Production run with monitoring | 2 weeks | First weekly batch, log review, tune retention window. |
Budget roughly 3–4 calendar weeks end-to-end for a first production anonymisation run, with the slowest item being the policy-plus-DPIA paperwork, not the recipe itself.
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.