# Recover something that was removed

Most removals in Connect are marks rather than erasures: a deleted conversation or call carries a deletion timestamp and the row is still there, and a modified file becomes a new version with the old one intact. What is genuinely irreversible is anything that has already left — a message a provider acknowledged, or a call that was placed.

- **Status:** Available
- **Audience:** both
- **In the app:** #/inbox, #/data
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/how-to/recover-a-deleted-record/

## The three kinds of removal

**Marked as deleted** — Conversations and calls carry a deletion timestamp of their own, alongside starred and priority. The record is intact; it has left your view.
**Superseded** — Files and memory work this way. A modification creates a new version or a replacing entry, and the previous state is still addressable.
**Closed or cancelled** — Follow-ups, cases and opportunities move to a terminal state rather than disappearing. The history of the commitment survives the commitment.

None of those three is an erasure, which is why the honest answer to 'can I get it back' is usually yes. The question worth asking first is which of the three happened, because they are recovered in different places.

## Getting it back

1. Identify what kind of record it was and where it lived.
   - Result: A conversation, a call, a file, a memory entry and a follow-up are five different recoveries. Guessing wastes the first ten minutes.
2. For a conversation or a call, look at the sheet in Data rather than at the screen it vanished from.
   - Result: The grid reads the same records the screens do, and a filter that does not exclude deleted rows will show it.
3. For a file, open its version list.
   - Result: The version before the change is readable, with the provenance of each version recorded. Restoring means creating a new version from the old content — the history stays complete.
4. For memory, re-record it at the tier it belonged to.
   - Result: Forgetting is intended to be final; there is no undelete. What matters is putting it back at the right tier, because the wrong tier will be overridden by something narrower.
5. For a follow-up or a case, reopen or recreate with the original reason.
   - Result: The reason is the part that is genuinely lost if nobody writes it down again, and it is the part whoever inherits it needs.

> **Note** Ask the Assistant to find the record before you go hunting manually. It searches across records rather than within one screen's filter, which is usually the reason something looks gone.

## What cannot be recovered

| Thing | Why | What to do instead |
|---|---|---|
| A sent message | The provider acknowledged it. It is in somebody's inbox and nothing here reaches it | Send a correction; the thread records both |
| A placed call | The conversation happened | The record, transcript and outcome remain — work from those |
| A forgotten memory entry | Forgetting is final by design, because a memory people cannot truly delete is not a memory people will trust | Re-record it at the correct tier |
| A row with no workspace stamp | It matches no scope and no policy, so it is invisible to every list rather than deleted | Not a user recovery; repair belongs to the schema owner at boot |

That last row is worth knowing about even though you cannot act on it. A record that was never stamped with a workspace is invisible rather than missing: every list omits it silently while direct actions on it still work. Two connected mail identities disappeared from a screen this way once, with no error and no duplicate warning.

## Reducing how often you need this page

- Prefer closing to deleting. A closed follow-up or case keeps its reason; a deleted one takes the reason with it.
- Save a view before a bulk action, so the set you changed is findable afterwards.
- Treat a do-not-contact entry as permanent by default. It is deliberately not casually cleared, and the Assistant cannot clear one at all.
- Use the Decision Log rather than memory when reconstructing what happened — it records refusals as well as actions, which is usually the half people are missing.

## Questions

### Is there a bin I can look in?

Not as a separate screen. Deleted conversations and calls are marked rather than moved, so the place to find them is the record list with the filter that excludes them turned off — the Data grid is the easiest way to do that.

### Somebody deleted a lot of rows at once. Can that be reversed?

Each row was changed through its owning service, individually, so reversing it means the same selection with the opposite action rather than a single undo. If the change was a deletion mark, the rows are still there to reselect.

### Can Connect delete something on its own?

Actions it takes are recorded as decisions, including refusals, so the Decision Log answers what happened and under which rule. If a record's state changed and nobody in your team did it, that log is where the account of it lives.

## Related

- [File versions](https://connectbyjbrh.com/docs/files-data/file-versions/)
- [Forgetting something](https://connectbyjbrh.com/docs/memory/deleting/)
- [Something will not delete](https://connectbyjbrh.com/docs/troubleshooting/cannot-delete/)
- [Data that should be here is not](https://connectbyjbrh.com/docs/troubleshooting/data-not-visible/)
- [Designing undo for agent actions](https://connectbyjbrh.com/research/undo-for-agents/)
- [Data that is invisible rather than missing](https://connectbyjbrh.com/research/workspace-stamp/)
- [Find out why Connect did something](https://connectbyjbrh.com/docs/how-to/audit-a-decision/)

## What this page is based on

- Connect source pack: overview (docs-source/sources/GENERAL.md §3 — the data model)
- Connect source pack: channels (docs-source/sources/CHANNELS.md §1 — the invisible-row defect)
- Connect capability registry (docs-source/facts.py — file_versions, audit_trail)