Forgetting something
Forgetting removes a memory row, so the claim stops reaching any future reply or call. It does not remove the conversation it came from, the record of decisions already taken, or a suppression that protects somebody from being contacted. Two deletions surprise people: forgetting a block unblocks the contact, and forgetting a memory does not delete the person.
What is actually removed#
One connect_memory row, at one tier. From the next piece of work onwards that claim is not read, not rendered into a brief and not carried into a draft. There is no soft period during which it still applies and no cache to wait out — a call already in progress rendered its brief once and keeps it, so the change lands on the following one.
It can be done from the memory viewer, from the memory sheet in the grid, or by asking the Connect Assistant, which has forget among its writing tools. All three go through the service that owns the record, so all three behave identically.
What survives on purpose#
| What survives | Why | Where it lives |
|---|---|---|
| The conversation | The thread, the messages and the call record are the history of what happened, not a claim about how things are | Conversations, and Customer 360 |
| The decision trail | What was decided, by what, under which rule, and what happened — including refusals | The audit trail |
| The person | A memory is about somebody; deleting it does not delete them | Relationships |
| A suppression or do-not-contact entry | It is a protection, not a preference, and is not cleared casually | Suppression, unsubscribe and do-not-contact |
The last row is the one worth dwelling on. Somebody who asked never to be contacted again is protected by a mechanism that is deliberately harder to undo than a memory row, and the Assistant cannot clear one at all — a request to "forget that they asked us to stop" is refused, and the refusal is itself recorded.
Two deletions with consequences#
Forgetting a workspace-tier row is felt everywhere at once. Because the broadest tier is applied to every piece of work, its rows are the ones most likely to be load-bearing for behaviour nobody remembers configuring. If a line looks obsolete, superseding it is the reversible move; deleting it is not.
Neither of these is a reason to be timid. Forgetting is meant to be easy, because a business that cannot remove what an agent believes has no real control over it. They are a reason to read the tags and the tier before you act, which takes a second.
Deleting everything about one person#
Filter the memory sheet in the grid to that person, and read the rows before removing them.
Result You see the tags at the same time, so a block is not deleted by accident along with the notes.
Remove the contact-tier rows in bulk.
Result The contact tier reads empty in the viewer, and future work falls back to the endpoint, channel and workspace tiers — which is a different thing from Connect having no context at all.
Decide separately what to do about the conversations, the person record and any suppression.
Result Those are three more decisions with three different consequences. Reviewing everything Connect knows about a person walks the whole set.
Questions#
Is a forgotten memory recoverable?
Treat it as not recoverable. If there is any chance the claim will be wanted again — a seasonal arrangement, a temporary constraint — supersede it instead, which keeps the wording readable while stopping it from governing anything.
If I delete a memory, does Connect forget the conversation too?
No. Threads, messages, calls and transcripts are separate records and stay exactly as they are. Memory is the set of durable claims layered on top of that history, and removing a claim does not remove the history that suggested it.
Can the Assistant delete anything a person can?
Not quite. It has forget and will use it on ordinary memory, but its rights are narrower than a person's: it cannot set pricing and it cannot clear a do-not-contact entry. Where it refuses, the refusal is recorded rather than passed over in silence.