The records Connect keeps
Connect keeps its own records rather than pointing at somebody else's. A workspace is the root; under it sit people, companies, conversations, calls, prospects, deals, cases, follow-ups, files, knowledge and memory. Every one of them carries the workspace it belongs to, and every one of them is visible as a sheet in the Data grid.
The root, and why it is on every row#
A workspace is the isolation root. Nearly every record carries its workspace identifier and is filtered by it automatically, which is what allows one database to hold the operator's records and every customer's without either seeing the other. A row with no workspace stamp is not a shared row — it is an invisible one, matched by no scope and no database policy, which is a failure mode worth knowing exists.
A small, deliberate set of tables sits outside every workspace, because they belong to the platform rather than to anyone using it: platform identity, sessions, billing, and enquiries addressed to JBRH through the public site.
The record families#
The Data grid at #/data is the plainest way to see the model, because every sheet in it is a real record type rather than a report built over one.
| Sheet | What one row is | What it is for |
|---|---|---|
| People | One human in the workspace's relationships | The thing every conversation, call and deal ultimately attaches to. |
| Companies | One organisation | Groups people, deals and cases under an account. |
| Conversations | One thread on one channel, with its messages | What was said, in order, with the direction of each message. |
| Calls | One call, inbound or outbound | Ring and answer times, provider status, transcript, summary, outcome and cost. |
| Leads | An enquiry that has not become a relationship yet | The front of the funnel, before qualification. |
| Prospects | An organisation or person found by research | Evidence, qualification and contactability — not yet a relationship. |
| Deals | One opportunity on the pipeline | Stage, value and the people it involves. |
| Cases | One post-sale support issue | The problem, its context and how it was resolved. |
| Onboarding | A new customer being brought into service | The steps between a won deal and a working account. |
| Follow-ups | A dated commitment on a channel, with a reason | What Connect promised, when it falls due and which channel it belongs to. |
| Knowledge | Source material the workspace supplied | What answers must be grounded in. |
| Files | One document, with its versions | What was uploaded or produced, and what changed between versions. |
| Memory | One durable thing learned, at a scope | What Connect knows about the business, a channel, an endpoint or one person. |
Mail exists twice, on purpose#
What a provider adapter fetches is stored in its own tables, in the provider's shape. The canonical thread, message and contact records — the ones the engine and every screen read — are written from them by a bridge. The engine never reads the provider's tables. That separation is the reason connecting a different mail provider changes nothing downstream: the canonical record looks the same whether it came from Gmail, Microsoft Graph or an IMAP server.
A person's own triage lives on the canonical rows rather than beside them. Priority, starred and deleted are columns on the thread and on the call, which is why correcting a priority changes what the engine picks up next instead of merely recolouring a row.
How the records join up#
- Identity → Person
- One address on one channel resolves to one human. A phone number, an email address and a WhatsApp number can all point at the same Person.
- Person → Company
- A person may belong to an organisation; the company groups their deals, cases and conversations.
- Conversation → Person
- Every thread and every call attaches to the relationship, which is what makes a single timeline possible.
- Follow-up → anything
- A follow-up carries the reason it exists and the channel it belongs to, so an unkept promise is traceable to the conversation that made it.
- File → record
- A document can be linked to the record it belongs to, and a change produces a new version with provenance rather than overwriting the old one.
- Memory → scope
- A memory belongs to one workspace, channel, endpoint or contact. The narrower scope wins where two apply.
What a record is not#
A record is not a transcript. A call transcript is evidence of what was said; the call record is the workspace's account of what happened, including who ended it and what it cost. A summary is written from a transcript and is deliberately refused where there was no conversation to summarise.
A record is also not memory. Knowledge is source material a workspace supplied, a Fact is one grounded statement drawn from it, and Memory is what Connect has learned. Keeping them apart is what allows a business to correct something Connect believes without deleting the document it came from.
Questions#
Can I edit these records directly?
Yes, in the Data grid, and every change goes through the service that owns the record rather than straight into a table — so a rule that applies when Connect writes a row also applies when you do.
If I disconnect a mailbox, do the conversations disappear?
No. Disconnecting stops further access to the provider; the canonical records already written stay in the workspace. Removing them is a separate, deliberate action.
Why are prospects separate from people?
Because a prospect is the result of research and has not agreed to a relationship. Keeping the two apart is what stops researched material being treated as though somebody had opted in.