Data retention

Set how long a form keeps its submissions and Faldaro deletes them for you — permanently, on schedule, and provably. Retention is off by default: nothing is ever deleted unless somebody sets a window.

Setting a window

Open the form: below its list of submissions, the Data retention row says what the form does today — Kept forever is how every form starts. Open the row and set a number of days; leave it empty to keep submissions forever.

It sits with the submissions rather than in the builder on purpose: everything in the builder is a draft that changes nothing until you publish, and this is the opposite — it takes effect on save, for records already collected.

The clock runs from a submission's last update, not its creation — a record still being worked on is not deleted out from under the person working it.

Changing this setting requires both form:write and submission:delete. Scheduling the deletion of every record a form will ever collect is a heavier act than deleting one by hand, so it needs the privilege that permits deletion, not merely the one that permits editing.

It applies to everything the form has collected

Retention is a property of the form, not of a published version. Setting it today reaches submissions made last year, against versions long since replaced. This is deliberate: a retention promise is about data, and the data you most need to delete is the oldest.

A consequence worth pausing on before you save: setting a short window on an established form can delete a great deal on the next sweep. The setting applies as soon as it is saved, with no publish step in between.

What deletion actually removes

The record and everything belonging to it:

The submission and every version of its data
Uploaded files — the stored bytes, not merely the reference to them
Generated documents, queued notifications and integration deliveries
Links to related submissions, and any agent runs against it

Payment records survive, with their link to the submission cleared. Financial history has its own obligations that outlive the record it priced, and quietly destroying it to satisfy a form setting would be the wrong default.

Deletion is permanent. There is no archive, no bin and no undo — that is what makes it worth something to a regulator.

Provable, in the audit log

Every purge writes an entry to the audit log naming the submission and the window it exceeded. Because the audit log is append-only at the database level, “we deleted it on schedule” is a claim you can evidence long after the data itself is gone — which is the half of a retention policy that auditors actually ask about.

When it runs

A sweeper runs hourly, so deletion happens within about an hour of a record becoming eligible rather than at a fixed time of day. Records are removed in batches, so a large backlog drains over several passes instead of one enormous burst.

Clearing the window, or lengthening it, always wins: a record that is no longer eligible when the sweeper reaches it is left alone. If you set a window by mistake, clear it — anything not yet swept survives.

Export submissions before setting a short window if you need a copy.
Deleting a form archives it and keeps its submissions; retention is the only feature that removes submitted data on a schedule.