Records · Retention and deletion
Multi-workflowCross-industryRetention schedules fail at deletion: workflows that find, hold and prove it
Almost every organisation has a retention schedule. Far fewer can show that anything was deleted because of it. This long read argues for treating deletion as a process with evidence, and shows how to build one.
Valnora & Elric team6 min read
Ask a compliance team whether they have a records retention schedule and the answer is almost always yes. Ask when something was last deleted because of it, and by whom, and the room goes quiet. The schedule exists; the deletion mostly does not.
That gap matters more than it used to. Data protection law expects personal data to be kept no longer than it is needed, and regulators increasingly ask to see the process, not the policy. At the same time, sector rules require certain records to be kept for set periods, and litigation holds can override both. Deleting too early is a breach. Deleting too late is also a breach. Deleting the wrong thing is worse than either.
This long read makes three arguments, then shows how to build the process in Agent Serve with three workflows.
Retention is a deletion problem, not a policy problem
Most retention programmes invest in the schedule: record classes, periods, legal bases, owners. That work is necessary, but it is the easy half. The hard half is operational. Records live in a CRM, a document store, a data warehouse, a ticketing system and a shared drive, each with its own idea of what a record is and how to remove one.
So the first useful step is to turn the schedule into data. Put it in a table: one row per record class, with the system that holds it, the event that starts the clock (account closure, contract end, last contact), the period, and the owner. Once the schedule is a table, a workflow can read it. A PDF cannot be read that way.
Holds must beat schedules every time
The most expensive retention mistake is deleting something under a legal hold or regulatory investigation. A sweep that ignores holds is worse than no sweep at all.
That is why the design puts the hold check in its own workflow, between finding candidates and deleting them, and why it is a rule, not a model judgement. The rule matches each candidate against the holds register by customer, account or matter reference. A match removes the record from the batch, every time, with no exceptions for confidence scores.
The same principle applies more widely: the decision to delete should be deterministic. Use AI where it reads well, such as summarising a batch for the approver or classifying unstructured documents into record classes before the sweep, and keep the deletion decision on rules and a person’s approval.
A deletion you cannot prove is only a claim
An auditor asking “how do you know these records were deleted” wants a record of each deletion: what, where, when, on whose approval, and whether it worked. A retention process without that log is a claim.
The log needs care. It should hold internal record references, the record class and the result, not copies of the personal data you just removed. And it should be written by the same process that did the deletion, so it cannot drift from what actually happened.
How the three workflows fit
Find, hold, delete, prove
Workflow 1 · Retention sweep
- 01Monthly scheduleA Schedule block starts the sweep on the cadence your records policy sets.
- 02Retention schedule tableOne row per record class: system, trigger event, retention period and owner.
- 03Query source systemsAPI and database blocks list records whose retention trigger date has passed.
- 04Candidates tableEach expired record is written as a candidate with its class and owner.
Workflow 2 · Hold check and approval
- 05Legal hold checkA rule matches candidates against the holds table by customer, matter or account.
- 06Summarise the batchAn Agent block writes a plain summary of what will be deleted, by class and system.
- 07Owner approvesA Human block pauses until the data owner approves or rejects the batch.
Workflow 3 · Delete and record
- 08Delete per systemA Loop calls each system’s delete or anonymise endpoint for approved records.
- 09Confirm it is goneA follow-up lookup checks each record no longer resolves.
- 10Deletion logRecord ID, class, system, approval, time and result. No personal data copied in.
- 11Failure monitorAlerts the records team when failed deletions pass a set count.
The retention sweep runs on a Schedule block, monthly for most classes. For each row in the retention schedule table it calls the relevant system through an API or database block, lists records whose trigger date plus retention period has passed, and writes them to a candidates table with their class and owner.
The hold check and approval workflow reads the candidates, applies the hold rule, and uses an Agent block to write a plain summary of the batch: how many records, which classes, which systems, how many were held back and why. A Human block then pauses the run until the data owner approves or rejects. Nothing is deleted while it waits.
The delete and record workflow runs the approved batch. It is started as a step from the approval workflow using the Workflow block, which runs another workflow as part of the same process. A Loop calls each system’s delete or anonymise endpoint, a second lookup confirms the record no longer resolves, and a Table block writes the result to the deletion log. Records that fail to delete stay on the log as failures, and a monitor alerts the records team when failures pass a set count.
What the solution produces
Deletion batch for approval (illustrative)
Record- Batch
- Closed savings accounts · CRM and document store
- Retention rule
- Account closure date plus the period in your records schedule
- Candidates found
- 1,840 records across 2 systems
- Held back
- 23 records matched an active legal hold and were removed from the batch
- Action
- Delete in the document store, anonymise in the CRM
- Approver
- Data owner, retail savings
Deletion log entry (illustrative)
Record- Record reference
- DOC-77120 (internal ID, no customer data)
- Record class
- Account opening documents
- System
- Document store
- Result
- Deleted · lookup confirmed not found
- Approved by
- Data owner, retail savings
Every run of each workflow is traced block by block in Logs, including inputs, outputs and errors. Workflows run from a deployed version, so a change to the sweep logic is reviewed before it touches production data.
Erasure requests use the same path
Individual erasure requests are the same problem at a smaller scale: find the person’s records across systems, check holds and legal reasons to keep them, get approval, delete, record. A small intake workflow, started by a Webhook trigger from your privacy request form, looks up one person’s records instead of one record class and hands them to the same hold check and approval. The rest of the path stays the same. Keeping one path means one set of controls to test, not two.
Limits, and where to start
Workflows can only delete what they can reach. Systems without a delete endpoint need a manual step, which the process can still track as a task with an owner. Backups follow their own retention cycle and need their own procedure.
Agent Serve also keeps its own data, such as run logs and chats. Set its data retention to match your schedule: retention can be set from one day to five years, or kept indefinitely, per organisation with overrides per workspace. If the records in scope cannot leave your environment, run Agent Serve self-hosted next to the systems it reads.
Controls and governance
Approvals before action
Relays never send email or book meetings without an approval, under any autonomy setting. An approval covers the exact payload the reviewer saw and expires if nobody decides.
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
Deployed versions
Workflows run from a deployed version, so a change is reviewed before it reaches production runs.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
GDPR ready
Retention from one day to five years, deletion and access controls support GDPR obligations. Ready means the controls are in place, not a certification.
Self-hosting
Run Agent Serve in your own cloud or data centre, next to the systems it reads.
More on how Agent Serve handles access, data and audit on the security page.
To start, pick one record class with a clear trigger event and a single system, such as closed-account documents in one document store. Build the sweep and hold check first and run them in report-only mode for a cycle, comparing candidates with what the data owner expects. Add the deletion workflow once the candidate lists are right. Then add the next class.
For the evidence side of the same discipline, see audit evidence collection. For turning policy text into checkable controls, see policy to control mapping.
What you need
- Your records retention schedule, broken down by record class and system
- API or database access to each system that holds records in scope
- A delete or anonymise endpoint, or an agreed manual step, for each system
- A legal holds register the workflow can read
- A named data owner per record class to approve deletion batches
- An agreed format for the deletion log your auditors will accept