Erasing personal data from Flowable for GDPR starts with knowing where the data sits
Picture an organization running Flowable BPMN processes for customer onboarding, complaints or employee requests, where task variables, form data and process instance details hold names, contact details and identifiers. The Flowable engine helps with the technical side of erasure, because it stores that data in runtime and history tables you control and gives you the means to delete or clean it. It does not decide whether a request must be granted. Under Article 17(1) of the GDPR, erasure is required without undue delay in six situations: the data is no longer necessary, consent is withdrawn, a valid objection is made, the processing was unlawful, a legal obligation requires erasure, or the data was collected from a child for information society services. Your legal and privacy team decides which ground applies to each process, and Article 17(3) exceptions, such as legal claims or legal retention duties, may keep some records in place.
The accountability duties sit with the controller. Article 5(2) requires you to demonstrate compliance with the principles in Article 5(1), and Article 24(1) requires appropriate technical and organisational measures that you can demonstrate and review. For Flowable, that means documenting which process definitions and data fields hold personal data, which history settings retain it, and how long each category is kept. Ask your privacy office to confirm the retention periods and lawful basis for each process before any cleaning job is scheduled, because the engine will not know those answers for you. DeployOpen can plan the system, configure and test the deletion routines, and prepare the evidence your assessors will ask for. DeployOpen does not certify GDPR compliance, and no audit report, attestation or certificate is issued by DeployOpen. Confirm with your supervisory authority or independent assessor which evidence they expect.
Mapping GDPR erasure requirements to Flowable capabilities and configuration
This table maps each GDPR erasure, notification, exception and accountability duty to the Flowable feature that affects it and the configuration or evidence you need. Flowable stores and deletes process data on instruction, but retention periods, legal holds and notifications come from your own policies. The main takeaway is that the engine can remove data, while demonstrating compliance depends on the rules and records you define around it.
| Requirement | What Flowable provides | Configuration and evidence |
|---|---|---|
| Article 17(1) erasure grounds | The engine does not decide whether an erasure ground applies to an instance. | Map each process definition to a retention rule and the ground that triggers deletion. Log the ground for each deletion. |
| Article 17(1) runtime data | Active instances keep variables in runtime tables until they complete or are deleted through the API. | Delete through the runtime service. Confirm variable rows are gone from the database for the affected instances. |
| Article 17(1) historic data | History tables keep variables and task data after completion, governed by history level and cleaning. | Set the history level to the minimum your purpose needs. Schedule history cleaning and confirm its scope in the Flowable docs. |
| Article 17(2) notification | The engine does not notify other controllers or integration targets that received the data. | Keep a list of downstream systems that received process data. Add a notification step to your erasure procedure. |
| Article 17(3) exceptions | The engine cannot evaluate legal claims, legal obligations or other exceptions. | Flag instances under legal hold so cleanup skips them. Record who approved the hold and when it ends. |
| Async executor and pending jobs | Timers and async jobs run on any node, so jobs can still touch data after the instance is removed. | Check job tables for jobs linked to erased instances before and after deletion. Confirm other nodes see the same state. |
| Identity references (Article 5(2) and 24) | User IDs in history remain after an account is removed. The identity service can be replaced. | Decide whether user IDs are pseudonymized. Use a custom identity service if names must resolve on read, and document the choice. |
| Article 24 and 30 accountability | The engine keeps run history but not your policies, approvals or processing register. | Keep erasure job logs, approvals and deletion counts as evidence. Maintain a processing register entry per process definition. |
Where personal data lands in Flowable runtime and history tables
Personal data can persist in Flowable long after a process completes, in more places than the business data model suggests. Process variables set during execution are the first place to check, because a variable holding a name, national identifier or email address is written to the database as the instance runs. Task data, such as form values and task-level variables, can also carry personal data. When history is enabled, the history tables keep copies of variables and activity records after the runtime rows are removed, so a completed instance may still hold the same personal data in history. Confirm in your Flowable version which history level you run and which variables it copies into history, since the level determines how much detail survives completion.
Two other stores often get missed in erasure reviews. The event log and any application logs written by your delegates, listeners or REST layer can record variable values, request payloads or error messages that include personal data, and these logs usually sit outside the engine's own tables. The async executor adds a timing dimension: timers and asynchronous jobs are stored in job tables with their own variables or references until they run, fail or are retried, so personal data in a waiting or failed job can outlive the instance it belongs to. Map the tables your database type actually creates. The configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types, and Spring Boot, embedded JAR and REST deployments can differ in where logs and connection pools write.
Build an inventory of every table and log that receives personal data before you design any deletion job. For each process definition, list the variables and task fields that hold personal data, then trace them into runtime, history, job and log stores in your own deployment. Ask your Flowable vendor or community which tables and columns hold variable values in the version you run, and test the result on a copy of production data. This inventory becomes the basis for the erasure design, the retention record and the evidence you show an assessor that erasure reaches every store.
What evidence to keep for an erasure audit trail
An erasure audit trail shows that a request was received, assessed, carried out and checked, and that any exception was applied on purpose. The cards below cover the records that prove each step, and each one should be kept in a form that does not reintroduce the personal data that was erased.
Retention schedule per process
Record, for each process definition, which variables and history fields hold personal data, how long each category is kept and which event starts the clock, such as task completion or case closure. Tie each entry to the Article 30 record of processing for that activity. Check that the schedule matches the history cleaning settings actually deployed, because a schedule that differs from configuration is weak evidence. Review it when process definitions change.
History cleaning configuration records
Keep versioned copies of the history cleaning settings, scheduler configuration and the job that removes historic data, along with the change record for each edit. Auditors will ask when a setting took effect and who approved it. Store the configuration in source control so the history of changes is preserved without copying any personal data into the repository.
Application deletion logs
Where your delegates or services delete personal data outside the engine, log the action with the request reference, the process instance identifier, the table or store touched, the number of records removed and the time. Do not log the deleted values themselves. A log that names the record and the operation shows what was done without preserving the data, which is the balance an auditor needs to see.
Erasure request register
Maintain a register of each data subject request with the date received, the identity verification outcome, the decision, the date completed and the reference to the deletion log. Record requests that were refused or partly refused. The register is the entry point for an investigation, so keep it in a system with its own access control rather than in the workflow data being erased.
Article 17(3) exception decisions
When retention continues because of a legal obligation, a legal claim or another exception in Article 17(3), record which exception applies, which data it covers, the reviewer and the planned end date. Each exception should be reviewed on a schedule, so the file shows that the retained data is not kept indefinitely by default. Legal teams should confirm each exception against your own jurisdiction and contracts.
Records of processing under Article 30
The record of processing activities describes which categories of personal data each workflow handles, the purposes, the recipients and the retention periods. Confirm that the record names the Flowable databases, history tables, log stores and backups that hold the data, since those are where erasure is most often incomplete. Update the record whenever a new process or variable is introduced.
Choosing between history cleaning, deleting historic instances and anonymisation
Scheduled history cleaning removes historic data in bulk on a timer, based on a retention rule you define. It suits cases where personal data sits across many finished instances and the retention period is consistent for each process. Its strength is repeatability. Its risks are that a rule can delete data you still need for a legal claim or an Article 17(3) exception, and that a bulk job cannot judge individual requests.
- Rule design: Define the cut-off (for example, instance end time, process definition or business status) and test it against a copy of production data before enabling it.
- Legal holds: Confirm how the job treats instances under a legal claim or another retention ground, since bulk rules apply the same test to every record.
- Run window and load: Cleaning large history tables competes with runtime work, so schedule it in a maintenance window and measure its duration in your environment.
- Run records: Keep a log of each run's scope and outcome so you can show the schedule operated as documented under Article 5(2).
Check which history level each process writes, because a cleaning job can only remove data the engine recorded.
Deleting specific historic instances through the engine API suits requests from an identified data subject, where you need to remove only that person's records. The main effort is finding every instance that holds their data, which is often wider than the business key suggests. Personal data can appear in variables, identity links, comments and linked child or parent instances.
- Locating data: Map which process variables, business keys and identity links carry the data subject's identifier. A search on the business key alone will miss variables.
- Running instances: Decide how to handle instances still in progress, since deleting one changes live work. Agree the rule with process owners before the request is processed.
- Related records: Test deletions in a non-production copy to confirm which related records are removed and which remain, including called processes and case or decision links.
- Authorization: Route each request through a documented approval step so you can show who authorized each deletion.
- Minimal request record: Log the request, the matched identifiers and the deletion time, while keeping that log free of unnecessary personal data.
Ask your test team to confirm, for your Flowable version, which history tables each delete call clears.
Removing or redesigning variables reduces the personal data a process stores, instead of deleting whole instances. Redesign lowers future exposure: store a reference to a record in your system of record rather than a name or contact detail, and fetch the details when a task needs them. Removal of existing values requires a targeted update across running and historic data. Effort comes from refactoring delegates, expressions, forms and DMN inputs, and from testing each change.
- Reference, do not copy: Store a record ID and read the details from the system of record when a step needs them, so the process holds less personal data.
- Variable scopes: Check how each variable scope is kept in history for your version before relying on transient or local variables to limit storage.
- Existing data: Clearing values in old instances needs a tested update that does not break task forms, decisions or sentries that read those values.
- Logs and listeners: Review application logs, event listeners and custom delegates, since they can print or forward variable values outside the engine.
- Decision inputs: Changing a variable that a DMN decision or CMMN sentry reads changes outcomes, so retest those paths.
Confirm how removal affects other tables in your Flowable version before scheduling the change.
Anonymisation is only a substitute for deletion when re-identification is no longer reasonably possible. The EDPB's announcement of 18 February 2026, on the 2025 coordinated enforcement action covering 32 DPAs and 764 controllers, lists ineffective anonymisation used instead of deletion among seven recurring challenges. The same announcement names deletion of personal data in backups as another. Hashing an identifier or replacing a name with initials often leaves the record linkable to a person, so it is weak evidence of erasure.
- Re-identification test: Check whether the remaining fields, logs or join keys could still link a record to a person, and record the result.
- Pseudonymised data: Treat pseudonymised records as personal data and keep them in scope for requests and retention rules.
- Backup retention: Confirm backup retention periods and whether erased data can be restored from older backup sets.
- Restore procedure: After any restore, re-apply erasure requests made since the backup was taken, and document the step.
- Processing records: Record the chosen method, the reason and the residual risk in your records of processing under Article 30.
Have legal and security owners approve the re-identification test and the backup procedure before relying on either.
Configuring Flowable for erasure and retention in sequence
This sequence finds where personal data sits in Flowable, sets how history is kept, builds and tests erasure, and confirms background jobs, backups and logs. It ends with a signed retention register that shows the decisions behind each deletion.
Inventory processes and variables holding personal data
Start with every deployed BPMN, CMMN and DMN definition, and list each process variable, case variable and expression input that carries personal data. Include identifiers in business keys, candidate groups and assignee fields, because these also persist in runtime and history tables. The data protection lead and process owners review the list together. The output is a register that maps each definition to its personal data fields, its lawful basis and the record of processing activities it supports under Article 30. The step is done when every deployed definition has a named owner in the register.
Set history level and history cleaning
Choose the history level the engine writes in each environment, because it decides which variables, activities and user actions reach the history tables. Set the level in your engine or Spring Boot configuration, then confirm in the configuration docs for your target version which cleaning or removal options exist for historic instances and how they are scheduled. Record the chosen level and the cleaning schedule per environment. Verify on a test database that a completed instance leaves history after the cleaning job runs, and keep the test output as evidence.
Design erasure handlers in delegates or the application
The engine does not know which fields are personal, so erasure is usually an application task. Write a Java delegate or application service that clears or replaces personal values in runtime variables, then removes or anonymizes the matching historic variables through the history service API in your version. Confirm the exact methods in the Flowable API reference for that release before you build. Test the handler on a sample instance in a non-production environment, and keep the code under change control so the erasure rule can be shown to an assessor later.
Confirm async job cleanup before erasing
Check the async executor before any erasure run, because timers and asynchronous jobs store data in the database and run from a thread pool across nodes. Confirm the lock owner and lock expiration behavior in the advanced docs so that jobs locked by a stopped node are picked up by another node and do not run against erased data. Confirm how failed or dead-letter jobs that reference an instance are cleared as part of the run. The step is done when a test run leaves no open jobs for erased instances.
Plan backups and logs for erasure
Erasing live tables does not reach backups, log files or event tables. The EDPB's 2025 coordinated enforcement action on the right to erasure named deletion in backups among its recurring challenges. Decide how backups expire, whether a restore must re-run erasure for affected instances, and where Flowable event logs and application logs store variable values. Mask or remove personal values in logs where your logging setup allows it. Confirm with your backup and log platform vendors how deletion propagates. The step is done when a written restore procedure covers erasure.
Record retention decisions and erasure evidence
For each process definition, write down how long history is kept, what triggers erasure, which Article 17(3) exceptions apply, and who approves a deletion. Keep erasure run logs, counts of erased instances and the test results as evidence for the accountability duty in Article 5(2) and the measures in Article 24(1). Auditors and supervisory authorities expect to see the decisions themselves, so link each retention rule to its register entry. DeployOpen can prepare this evidence, but an independent auditor or certification body issues any audit report. The step is done when the retention register is signed off by the controller.
What Flowable does not decide for you under GDPR
Flowable stores and runs process data, but it cannot decide what the data is for, how long it may be kept, or what happens outside the engine. The cards below mark the decisions and actions that stay with your organization and the people who run the platform.
Lawful basis and retention periods
Article 5(2) makes the controller responsible for demonstrating compliance with the principles in Article 5(1), and Flowable has no field that records why a process collects data or how long it may be kept. Your privacy team must set a lawful basis and a retention period per process, then encode them as a history cleaning schedule. Ask who signs off each retention period and where that decision is recorded.
Which variables are personal data
The engine stores process variables as they are passed in and does not classify them. A free-text field, an email address or a national ID placed in a variable is personal data to the GDPR, while a status code may not be. Build a variable inventory for each process definition, and confirm that delegates, expressions and external workers do not copy those values into logs or event records.
Backups and copies outside the engine
Deleting rows from runtime and history tables does not remove personal data from database backups, replicas, search indexes, exported reports or data warehouses. The EDPB's 2025 coordinated enforcement action listed deletion of personal data in backups among recurring erasure challenges. Document how long backups persist, how restored data is re-erased, and which copies sit outside Flowable.
Notifying other controllers
Article 17(2) requires a controller that has made personal data public to take reasonable steps, including technical measures, to inform other controllers processing the same data of an erasure request. Flowable does not track which recipients received data or which systems hold copies. Maintain a register of disclosures from each process, and define how erasure requests reach downstream controllers.
Certification does not replace accountability
The GDPR requires no audit, attestation or certificate. Article 42 certification is voluntary, is issued for at most three years, and does not reduce the controller's or processor's responsibility for compliance. A vendor or implementation partner cannot certify your erasure process on your behalf, so your records, procedures and test evidence must show compliance directly.
How much work is GDPR erasure in Flowable, and can our team do it?
What makes GDPR erasure in Flowable more or less work?
The main drivers are how many process definitions and case models hold personal data, how many variables each instance carries, the history level the engines run at, and how many data stores and backups hold copies. More processes and more variables mean more mapping and more cleanup logic. A higher history level records more personal data per instance, which widens the erasure scope. Each database, log store, search index, file store and backup set that receives copies adds a separate deletion path to design, test and document. Ask the partner to count these items in the written scope before estimating anything else.
Can our internal team do GDPR erasure in Flowable on its own?
Often yes, if the team already runs Flowable and knows its database schema, history tables and deployment pipeline. The work needs Java and SQL skills, access to every data store, and time to test deletions against a copy of production data. Teams without that experience usually find the hard parts are tracing where personal data was copied and proving that deletion worked. An outside partner can take on the mapping, the scripts or jobs, the test evidence and the written retention record, while your staff keep ownership of decisions. Decide which of these parts you want to keep in-house before requesting a quote.
What do legal and data protection staff need to provide?
Legal and data protection staff decide what must be erased, what must be kept, and for how long. Article 17(1) lists six grounds for erasure without undue delay, and Article 17(3) lists exceptions such as compliance with a legal obligation and the establishment or defence of legal claims. Article 5(2) makes the controller responsible for demonstrating compliance, so the retention rules and their reasons must be written down and approved by the controller. Engineers cannot make these calls. Ask for a named owner on the controller side who signs off the retention periods before build work starts.
How does the environment change the timeline for erasure work?
The timeline depends on the environment more than on the Flowable code itself. Relevant factors include the database type, since Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, the backup rotation and restore process, how many environments hold copies, and whether change control or release windows apply. Backups deserve early attention because the EDPB's 2025 coordinated enforcement action on erasure named deletion of personal data in backups as a recurring challenge. Ask for the timeline to be split into discovery, build, test and rollout phases, with each phase tied to deliverables in the written scope.
What should we request in a written scope for erasure work?
A written scope should list the process definitions, case models and decision models in scope, the history level and event logging settings, and every store that holds personal data. It should name the erasure triggers, the retention rules supplied by the controller, and how deletion of historic instances will be run and verified. Ask for the deliverables to include a retention document, test records showing deletion from runtime, history, event and log tables, and the backup handling approach. Also request a clear statement of what is not included, such as legal interpretation or certification, since DeployOpen does not issue audit reports, attestations or certifications.
Does erasure work recur after the first implementation?
Yes, parts of it recur. New process definitions, new variables that carry personal data, Flowable version upgrades and new data stores all require the erasure mapping and jobs to be reviewed. Scheduled history cleaning and periodic checks of logs and event tables need an operator. The one-time work is the initial mapping, the build and the first evidence set. Recurring work is the review cycle, the retention record updates and any support retainer. DeployOpen offers ongoing support as a retainer, so ask whether the quote separates one-time build fees from recurring review effort.
What does a Flowable upgrade mean for erasure jobs?
A Flowable upgrade can change the schema, the APIs and the Java baseline that your erasure code depends on, so the jobs must be retested after each upgrade. The Flowable 8.0.0 release notes describe an upgrade to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, so teams on older stacks should plan that change alongside erasure work. Ask for the erasure tests to be part of the upgrade acceptance criteria so that deletion behavior is checked each time the engine changes.
Keeping erasure controls current as GDPR and Flowable change
The GDPR text has not been amended as of October 2026, so the erasure duties in Article 17 and the accountability duties in Article 24 are the same obligations your Flowable erasure design was built against. Two amendment proposals are still moving through the EU process: Omnibus IV (procedure 2025/0130(COD)), where a text was agreed in negotiations on 26 June 2026 but still awaits Parliament's first-reading vote, and the Digital Omnibus (procedure 2025/0360(COD)), which awaits committee decision. Regulation (EU) 2025/2518 on procedural rules for cross-border enforcement applies from 2 April 2027, which is a date to put on the compliance calendar even though it does not change what you must erase. Ask your privacy counsel to confirm the status at the time of each review, since these procedures move.
Article 24(1) requires measures that are reviewed and updated where necessary, so the erasure design needs a trigger. The most useful trigger is a Flowable version change. Flowable 8.0.0, released on 27 February 2026, moved the stack to Spring Framework 7 and Spring Boot 4, made Jackson 3 the default JSON library, and removed JUnit 3 and 4 support. Any of those changes can alter how variables are serialized, which tables hold them, or which test fixtures verify your cleaning jobs. Before upgrading, re-run the erasure test suite against a copy of production history, confirm the history cleaning schedule still executes, and check that variables stored in the event and log tables are still masked or purged as your records of processing describe.
Tie retention reviews to upgrades, not to a calendar alone. Each review should compare the current retention setting for each process definition against the lawful basis and the Article 30 record of processing activities, and record who approved any change. Keep the evidence (the review minutes, the diff of cleaning job configuration, and the test output) with the change record so an assessor can see that the control was re-tested after the platform changed. Note that compliance certification does not replace this work: the GDPR requires no audit or attestation, and an Article 42 certification, where you hold one, does not reduce your own responsibility.
How DeployOpen scopes and delivers GDPR erasure configuration for Flowable
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including Flowable engines in your Java stack. For erasure work, we start from where personal data actually sits in runtime and history tables, then agree a written scope before any configuration changes are made.
How we scope
- Inventory the process definitions, variables and history tables that hold personal data for each Flowable application
- Agree in writing which erasure, anonymization and retention actions are in scope and which are excluded
- Confirm with your data protection team which retention periods and lawful grounds apply to each process
- Document the scope, deliverables and timeline in a written agreement before work starts
How we build
- Configure history cleaning schedules and retention settings in the Flowable engine and its deployment
- Build or adjust custom delegates so personal variables are removed or minimized at defined points
- Review application logs and event tables to find personal data that would survive a history deletion
- Test erasure runs in a non-production copy of your database before any change reaches production
How we hand over
- Deliver a record of processing and retention settings for each Flowable application in scope
- Provide runbooks describing how erasure jobs are run, monitored, verified and rolled back
- Hand over test evidence showing which records were removed and which were retained, with reasons
- Confirm with your legal and compliance teams that the documentation matches the implemented configuration
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover Flowable version upgrades, so erasure settings are rechecked against each release
- Review changes to retention rules or new processes that touch personal data before they go live
- Clarify with your counsel how the GDPR applies to your organization, since DeployOpen does not provide legal advice
