Data retention
Have a process delete the data a run produced once the run is over, so sensitive values are not kept longer than you need them.
Data retention tells a process to delete the data a run produced once the run is over. You set it per process, and separately for runs that succeed, runs that end with an error, and runs that a user stopped.
It exists for privacy: regulations such as GDPR and HIPAA expect personal data to be kept no longer than it is needed. If a process handles ID numbers, medical data, bank details or anything else you would rather not keep, this is the setting that disposes of it without anyone having to remember to.
Verified on 4 November 2026.
Set it for a process
- Open the process in the Process Designer.
- Open Data retention in the canvas sidebar.
- Choose what should happen for each of the three outcomes.
- Save the process.
There are three choices, and each of the three outcomes takes its own:
| Option | What it means |
|---|---|
| Never | Keep the run's data. Nothing is deleted automatically. |
| At end of runtime | Delete the data as soon as the run finishes. |
| At move to history | Keep the data while the run is recent, and delete it when the run moves to history. |
Which outcome is which
- Delete data on process success — the run finished normally.
- Delete data on process error — the run stopped because an action failed.
- Delete data on process stopped by user — someone ended the run with Stop instance.
They are separate on purpose. Keeping the data of a failed run while discarding the data of a successful one is the common setup: the failures are the ones you still need to look at.
A process you create in the designer starts with all three set to "At move to history", not to "Never". If you need a run's data to stay available indefinitely — for an audit trail, say — set the outcomes you care about to Never yourself.
A process created over the API has no retention setting of its own and follows the workspace setting instead. So the default above is the designer's, not the platform's: if you build processes through the API, the workspace setting is the one that decides what happens to their data.
Delete one run's data by hand
A single run can also be cleared on its own, whatever the process's setting says.
- Open the run and go to its Data retention tab.
- Choose Delete data of the instance.
Use this when one particular run picked up something it should not have kept.
Deleting a run's data cannot be undone. The run itself stays in the list with its status and timings; the values it carried are gone.
What is deleted, and when
| Option | What you see afterwards |
|---|---|
| Never | Everything stays, including after the run moves to history. Output files remain downloadable. |
| At end of runtime | The variable values — output files included — are already empty by the time the run ends. Even the response of a synchronous run comes back without them. |
| At move to history | The values stay readable while the run is recent, and are emptied when it moves to history. After that, a download of one of its output files is refused. |
In every case the run itself remains in the Instances list, with its status, its timings and the number of actions it consumed. Data retention removes the run's data, not the record that the run happened — and it never changes what the process does on its next run.
"At move to history" is not immediate. A finished run stays in the recent list first, and the deletion happens when it moves to history. There is no fixed period — how long it takes depends on the run, and it is not a time you can set. If you need the data gone the moment the run ends, choose At end of runtime.
Related
- Running a process — where runs and instances come from.
- Stop a running process — what the "stopped" outcome means.
- Debug a process — inspecting a run's values while it is still going.
Stop a running process
There could be various circumstances where you might want to cancel the execution of a process. For instance, if the process is taking an excessive…
Set process notifications
Get an email when a process run succeeds or fails, for every run or only for the runs started by one schedule.