Data retention

By default a workspace keeps feedback forever. A retention policy changes that: it sets a window, in days, after which feedback messages are archived and then permanently deleted.

The setting itself is one number on the Admin Controls page. What it sets in motion is more interesting.

Why a policy rather than a delete button

Retention is a standing commitment, not a cleanup task. The point of setting a window is that you no longer have to remember to do anything — and, more importantly, that you can tell someone what the window is. “We keep feedback for 180 days” is a sentence you can put in a privacy notice, and a retention policy is what makes it true without anyone having to act on it.

That is also why the window has a floor. The minimum is 30 days and the maximum is 3650 (ten years). Thirty days is short enough to be a real commitment and long enough that a policy set carelessly on Monday hasn’t destroyed last week’s survey by Tuesday.

What happens when the window passes

Setting a policy registers a daily schedule for the workspace. Once a day it computes a cutoff — today minus the retention window — and processes everything older in three steps.

First it exports. Expired messages are serialised to an NDJSON archive, one record per line, carrying the message id, its conversation, its role, its content, and its timestamp. The export runs as a distinct step before anything is deleted, so the purge never runs against data that hasn’t been captured. Retrieving that archive is not a self-serve action in the app — treat the purge as final and take your own export first if you need the data.

Then it purges. The expired messages are deleted in batches, each batch inside a transaction. This is a real deletion, not an archive flag.

Then it repairs what pointed at them. Signal events that cited a purged message as evidence keep existing — the insight, its severity, its description — but the purged ids are removed from their source list and the event is marked as having had sources purged. You keep the finding; you lose the ability to click through to the raw message. That trade is deliberate: a retention policy is a promise about messages, and silently deleting every conclusion ever drawn from them would be a much larger promise than anyone intended to make.

Each run writes an audit entry recording how many records were exported and how many purged.

What is never deleted

Three things are explicitly out of scope, and it is worth knowing why.

Audit logs. They are the compliance record. A retention policy that could erase its own evidence would be worthless, so the purge never touches them — including the entries the retention runs themselves write. See Audit log.

Active conversations. Only messages in conversations that have ended are eligible. A survey still collecting responses is never pruned mid-flight, however old some of its messages are.

Signal events. As above: preserved, with their source references trimmed.

Choosing a window

The presets — 90, 180, and 365 days — exist because they map onto the periods organisations usually commit to. A custom value is available for anything else within the 30-to-3650 range.

The consideration that matters most is comparison over time. If you run a Recurring Survey Series and care about trends, your retention window is also your maximum comparison window. A 90-day policy makes a year-over-year comparison impossible, and it will do so quietly — the trend simply thins out. If long-run comparison is the point of your programme, set the window with that in mind rather than defaulting to the shortest number that feels responsible.

Turning it off

Remove Policy clears the window and cancels the daily schedule. Feedback is retained indefinitely again from that moment.

It does not restore anything already purged. Removing a policy stops future deletion; it does not undo past deletion.