The memory viewer shows nothing

What the symptom looks like#

The viewer opens, the tiers are listed, and one or all of them are blank. Nothing spins, nothing errors, and there is no message explaining the absence — which is exactly why it reads as a fault rather than as an answer.

It is worth distinguishing from the neighbouring complaint. "The viewer is empty" and "Connect ignored what I saved" feel like the same problem and are usually not: the second means a memory exists and is being outranked, and it is diagnosed differently.

What it means#

Memory is held at four tiers — workspace, channel, endpoint and contact — and every tier that applies to the thing you are looking at is returned, including the ones that are empty. Empty tiers are deliberately kept rather than dropped, so that a blank is a statement rather than a silence.

The second thing it means is that Connect stores less than people expect, on purpose. Memory is written deliberately — by a person, or by a person accepting something Connect drew out of a conversation. A workspace that has been running for a fortnight without anybody writing anything will have a genuinely empty viewer, and that is the system behaving correctly.

The likely causes, most common first#

You are on a narrower tier than the memory

The direction was written at workspace tier and you are reading the contact panel. The contact tier is empty and correct; the memory is one level up and applies perfectly well.

The viewer was opened from a different mount

It mounts from the mailbox row, the channel screen and the contact panel. Each shows the tiers relevant to where it was opened from, so the same viewer answers a different question depending on where you started.

The history is on a second person record

The address you are looking at resolved to a different person from the one the memory was written against. Search the address rather than the name to see whether two records exist.

The wrong workspace is active

Everything is scoped to one workspace. In the wrong one the record is genuinely absent rather than empty, and every other screen will look subtly thin too.

It is a directive, not prose

A block is held as a block:<channel> tag rather than as a sentence. Reading only the bodies makes an active block look like nothing at all.

Nothing was ever written

The most common cause overall, and the easiest to dismiss. Accepting a suggestion in a conversation is what stores it; reading it and moving on does not.

What Connect completed#

• It resolved the workspace and read only that workspace's memory.
• It resolved every tier that applies to what you opened, and returned each one — including the empty ones, which is why you can see that they are empty.
• It applied whatever memory does exist to the work in that scope; an empty contact tier does not stop a workspace-tier direction being followed.
• It kept provenance on everything that is stored, so anything you do find can be traced to who said it and when.

What Connect did not complete#

• It did not gather memories from conversations by itself. Something durable is proposed and then kept by a person; nothing is stored silently because it was mentioned.
• It did not merge two person records. Duplicates are proposed; the merge is a human decision, so history split across two records stays split until somebody joins them.
• It did not look in another workspace, or at another tier's contents, to fill an empty panel with something plausible.
• It did not convert a prose instruction into a directive. A sentence asking that somebody not be contacted is a note; only the tag stops anything.

What you can do, and what an administrator can do#

1. Read the tier labels before concluding anything, and check which one you are actually on.

   Result Most reports end here. An empty contact tier beside a populated workspace tier is a normal, healthy record.

2. Search the customer's address rather than their name.

   Result A duplicate record is visible immediately, and merging it restores both the memory and the history under one person.

3. Write one memory at the tier you expected to find something, then reopen the viewer.

   Result You have proved the viewer works and learned which tier that mount point shows, in about a minute.

An administrator can confirm the workspace, check whether the person record is one of a pair, and review what has been written across the whole workspace rather than one panel at a time. If a record is present in a database export and absent from every list, that is the one shape of this problem that is a genuine defect — a row stamped with an empty workspace matches no scope and no row-level security policy, and is repaired by migration rather than from a screen.

Questions#

Related#

• Seeing what Connect knows
• The four memory tiers
• Writing a memory, end to end
• Connect ignored what I told it
• Block and guidance directives
• Merging two records
• You are in the wrong workspace
• Person memory