Seeing what Connect knows
Everything Connect has learned is readable. The viewer opens from the mailbox row, the channel screen and the contact panel, and it groups what it shows by the tier that owns it — including tiers with nothing in them. For a whole tier at once, the memory sheet in the Data grid is the same records in a table you can sort, filter and export.
Three doors into the same records#
| Open it from | What you are looking at | What you would use it for |
|---|---|---|
| A contact panel | That person, with the three broader tiers above them | Understanding why a reply to one customer read the way it did |
| A mailbox row | That endpoint, with channel and workspace above it | Checking what a particular address has been told about itself |
| A channel screen | That medium, with the workspace above it | Auditing tone and length rules that apply to every conversation on a channel |
| The memory sheet in Data | Every row in the workspace, in a grid | Reviewing, filtering or exporting the whole set |
The three in-place doors exist so that reading what Connect knows does not require leaving the work. Somebody looking at a difficult thread should not have to navigate to a settings area, find the right person and come back with the answer half-remembered.
How it is grouped, and what an empty group means#
The grouping is by owning tier, in resolution order, because that is the order the reply was assembled in. Reading top to bottom shows you the business first and the individual last, which is how a colleague would brief you on an account.
A tier with nothing in it is shown as an empty group rather than hidden. This is the single most useful thing the screen does. "Contact: nothing set" is a real answer to "why was that reply so generic"; a missing heading would have left you wondering whether the section was absent or the data was. tiers() returns the empty set for the same reason — the honest shape of the answer includes the parts that are empty.
The grid route, and what it is not#
Memory is one of the thirteen sheets in the #/data grid. It is virtualised, so a large workspace opens without waiting, and it sorts, filters, groups, freezes columns, saves views, edits inline, acts in bulk and exports to CSV with formulas neutralised. That makes it the right surface for the periodic read-through that keeps a workspace tier honest.
Asking rather than browsing#
The Connect Assistant has recall among its read-only tools, so "what do you know about this customer" is a question you can put in words rather than a screen you have to find. It answers from the same rows, under the same workspace isolation, and it cannot see a record the session it is running in could not see.
Browsing is still worth doing occasionally. An answer to a question tells you what is there; reading a tier end to end tells you what is missing, which is usually the more interesting fact when replies have been correct but oddly impersonal.
Questions#
Can a customer workspace see all of this?
Yes. Memory runs on one implementation for both audiences, so an Owner session and a tenant session see the same screens over the same records — a tenant's requests simply arrive on the customer API path. There is no reduced memory view for a customer.
Does reading memory count against any allowance?
No. Plan allowances bound outbound work and model usage, not reading your own records. You can read every tier as often as you like, and the periodic read-through this page recommends costs nothing.
Can I export what Connect knows about one person?
The memory sheet in the grid filters and exports to CSV, with formulas neutralised so an exported cell cannot execute in a spreadsheet. Filtering to one person and exporting is the usual way to answer a request to see everything held about them.