# What is kept and for how long

Retention is decided per class of record rather than by one clock over the whole workspace. Working records live as long as the workspace does unless somebody removes them; the accountability trail and compliance entries are kept deliberately longer, because both exist to answer questions after the fact. Where a specific period applies, it is stated on that record's own page.

- **Status:** Available
- **Audience:** both
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/security/data-retention/

## Four classes, four different rules

| Class | Examples | What governs how long it stays |
|---|---|---|
| Working records | Conversations, calls, follow-ups, opportunities, files | The workspace. They stay until a person removes them or the workspace is removed |
| The accountability trail | Decisions, approvals, refusals | Its own retention rule, deliberately longer than the working record |
| Memory | What Connect knows about the business and its people | A person. Any tier can be read and any entry forgotten, at any time |
| Compliance entries | Suppression, unsubscribe, complaints, do-not-contact | A deliberate act. These are not aged out on a timer |

Reading the table as one rule with exceptions gets it backwards. The classes have different purposes, so they have different rules: a conversation is work, a decision is evidence about work, memory is instruction, and a do-not-contact entry is a promise. Only the first of those is sensible to expire on a schedule.

## What deleting something does

Removing a conversation marks it rather than erasing the row underneath. That is what makes the action reversible in the short term and what stops a deletion from taking related evidence with it — the decision that produced a reply is not annihilated because somebody tidied their inbox. The record leaves every list immediately, which is the behaviour a person is asking for.

Forgetting a memory is different: it is meant to change behaviour, so the entry stops applying at once and the engine stops being given it. [Memory in Connect](/docs/memory/) covers the four tiers and what forgetting at each one affects.

> **Careful** Clearing a suppression is not tidying. A do-not-contact entry is removed by a deliberate act or not at all, and the Assistant cannot remove one — it is a right the tools are not given, rather than a step they skip.

## The two kept longest, and why

**The decision trail.** Questions about an automated system arrive late: months after a message went out, somebody asks why. A trail that had been trimmed to keep a database small answers that question with silence, which is indistinguishable from the system having done something it should not. Its period is published on [How long the record is kept](/docs/autonomy/audit-retention/).

**Compliance entries.** An expiry on a do-not-contact entry is a mechanism for eventually contacting somebody who asked not to be contacted. Nothing about a timer makes that acceptable, so there is no timer; a suppression stops applying when a person decides it should and not before.

## When a workspace goes

Removing a workspace is the one operation that ends every class at once, which is why it is a workflow with its own page rather than a button. [Removing a workspace, end to end](/docs/workflows/workspace-deletion/) sets out what is removed, what order it happens in, and what cannot be undone afterwards.

Two things sit outside every workspace by design and are unaffected by it: platform identity — the account you sign in with — and enquiries addressed to the operator through the public site. Neither belongs to a customer workspace, so neither leaves with one.

## What this page does not claim

- No single number of days for everything. A page that gave one would be tidier and wrong.
- No certification. Connect holds none, and a retention practice is not one.
- No promise about a future retention control. What is described here is what exists today.
- No statement that a removed record is unrecoverable from a backup on the same day it was removed. Backups are an operational matter and follow their own schedule.

## Questions

### Can I export what a workspace holds before removing it?

The data grid exports the sheets it covers as CSV, with spreadsheet formulas neutralised so an export cannot execute anything when it is opened. Files keep their versions and provenance. Doing that before a removal is worth the ten minutes, because the removal itself is not reversible.

### Does Connect train a model on a workspace's data?

No. Retention here is about records the workspace can read and act on. Training a model on customer content is not something Connect does, and no retention setting changes that either way.

### If I delete a conversation, does the decision about it disappear too?

No, and that separation is deliberate. Removing work is a person's choice; removing the evidence of what an automated system decided is not the same act, and collapsing the two would make the trail worthless.

## Related

- [How long the record is kept](https://connectbyjbrh.com/docs/autonomy/audit-retention/)
- [Who can read the audit trail](https://connectbyjbrh.com/docs/security/audit-access/)
- [Removing a workspace, end to end](https://connectbyjbrh.com/docs/workflows/workspace-deletion/)
- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)
- [The suppression list](https://connectbyjbrh.com/docs/email/suppression-list/)

## What this page is based on

- Connect source pack section 3 — soft deletion on canonical rows, control-plane tables outside every workspace (`docs-source/sources/GENERAL.md`)
- Connect source pack section 1 — compliance checked in one place; the Assistant cannot clear a do-not-contact entry (`docs-source/sources/CHANNELS.md`)
- Connect capability registry (`docs-source/facts.py`) — `audit_trail`, `memory_editing`, `suppression_dnc`, `data_workspace`