Something will not delete
Three kinds of thing resist removal, for three different reasons: the accountability trail, because a record you can erase proves nothing; entries that protect somebody, such as a do-not-contact instruction; and anything with history hanging off it, which is marked rather than erased so the history survives. Only the first is absolute.
What is protected, and why#
| Thing | What happens | Why |
|---|---|---|
| The audit trail | Nothing removes an entry | Its whole value is that it cannot be edited by the person it describes |
| A do-not-contact instruction | Cleared only deliberately, by a person | It exists to protect somebody outside the workspace, so it is not casual to undo |
| Suppression from a bounce or a complaint | Cleared only where clearing is legitimate | Removing it re-enables sending to somebody who asked not to be sent to |
| A conversation, a call, a person | Marked as removed and taken out of lists | The history stays attached to the relationship it belongs to |
| A file | Changed by adding a version, with provenance | So the earlier content and who changed it remain answerable |
| A memory | Genuinely forgotten, at any tier | What Connect knows is meant to be correctable by the person it is about |
Removed, or marked as removed?#
Most 'delete' actions here mark the canonical row rather than erasing it. The item leaves every list, stops appearing in exports and stops being picked up as work, while the relationship keeps its history. That is why a removed conversation can still be reached by a direct link and why a removal does not cascade through everything the record touched.
A row you cannot see cannot be removed either. Every record belongs to exactly one workspace and is filtered three times before it reaches you, so a record without a workspace stamp is invisible rather than missing — and invisible things cannot be selected, let alone deleted.
What Connect completed#
The refusal itself, recorded as a decision with the rule behind it. Where the action was a mark rather than an erasure, the mark was applied and the item has left every list it was in. Nothing is half-done: an action that was refused did not partially run, and one that succeeded is reflected everywhere the record is read from, because the change went through the service that owns it rather than through the screen.
What Connect did not complete#
It did not erase the underlying row, and on a refusal it changed nothing at all. It also did not remove copies that live outside it: a message already sent exists in the recipient's mailbox, and an export already downloaded is on somebody's machine. Neither is reachable from here, and no page in this documentation should imply otherwise.
What you can do#
Decide what you actually want: hidden from view, stopped from acting, or genuinely gone.
Result The three have different mechanisms, and asking for the wrong one is why most of these reports start.
To stop Connect acting on something, close it or change autonomy rather than removing it.
Result The record stays, the work stops, and the decision is on the accountability trail — which is usually what an auditor will ask about later.
To correct something Connect believes, forget the memory.
Result Memory is editable at every tier and is the one class of knowledge designed to be removed by the person it concerns.
To stop contact with somebody, block the channel or suppress them.
Result A block is held as a directive against the contact, so it holds across channels and across future conversations rather than depending on a record continuing to exist.
What an administrator can do#
- Confirm which protection applied. A refusal on a do-not-contact entry and a refusal on a record with dependents are different conversations with different outcomes.
- For a genuine erasure request from the person the data is about, follow the data-request workflow rather than deleting by hand — the obligations and the evidence are documented there.
- Check the workspace stamp when a record cannot be selected at all. Invisible and undeletable look identical from a screen and are entirely different problems.
When to escalate#
Escalate when a person exercising a right over their own data needs something genuinely erased, and when a removal appears to have succeeded on one screen and not on another — the second means two surfaces are reading different things and is a defect. Do not escalate a refusal on the accountability trail: that one is working as intended, and the answer will not change.
Questions#
Can anybody remove an audit entry?
No. An accountability record that the people it describes can edit is not an accountability record. Entries never carry secrets in the first place — a credential is recorded as having been set, never as its value — so there is rarely a legitimate reason to want one gone.
I removed a conversation and the person's history still shows it.
That is the design. Removal marks the row and takes it out of lists; the relationship keeps its history, because a timeline with silent gaps is worse than one showing something you have hidden from your own inbox.
The Assistant says it cannot clear a do-not-contact entry.
It cannot, and that is not a configuration you can widen. Clearing one is a decision about somebody outside the workspace, and it is reserved to a person.