Answering a customer's data request

What is actually held#

The export is of records, not of screens. A CSV from the grid contains the same values the screens read, because the grid is a view over the services that own the records rather than a second copy of them.

A request, stage by stage#

1. Trigger — a customer asks the business what it holds about them, or asks for it to be corrected or removed.
2. User event — the request arrives on an ordinary channel. It is a business decision, so it is escalated rather than answered automatically.
3. Authentication and workspace resolution — the answer is assembled inside one workspace. There is no query that spans workspaces, for anyone.
4. Ingest — the request is recorded like any other message, which also dates it.
5. Canonical record — the person is resolved to one Person record; identities on different channels resolve to the same human rather than to several.
6. Classification — access, correction or deletion. They have different answers and different consequences.
7. Knowledge and rules — whatever the business has set out about how it handles these requests. Connect does not supply that policy.
8. Approval — a person decides that the request is genuine and that the requester is who they say. Connect does not verify identity for this purpose.
9. Action — the record, the timeline, memory and the exports are assembled; corrections and deletions are made in the service that owns each record.
10. Result — a set of records the business can send, and a note of anything deliberately excluded.
11. Relationship and timeline — the request and its answer sit on the person's history, which is where the next person looking will need them.
12. Audit — the actions taken are in the decision record, including deletions, so the business can show what it did.

The limits, stated plainly#

• Nothing outside the workspace. Isolation is enforced three times over — an allowlist in the middleware, the workspace kernel in the ORM, and row-level security in the database — so a request cannot reach another workspace's data even in principle.
• Website enquiries addressed to the operator are not workspace data. They live outside every workspace by design. A customer asking why an enquiry is not in their workspace is seeing isolation working rather than a fault.
• Derived text is derived. A summary, a relationship story or a next-best-action is generated from the underlying records. It is exportable, but the record it came from is the original.
• Provider-side copies are the provider's. Mail sits in the mail provider as well as here; removing a message from Connect does not remove it from the mailbox it came from.
• Sent is not recallable. A message the provider acknowledged has left; the record of it stays, and that record is part of what a request would return.

Correction and removal#

1. Correct the record first — name, company, stage, identities.

   Result The record is what every screen and the engine read, so this is the change with the widest effect.

2. Then correct memory, at every tier that carries the claim.

   Result Memory resolves narrowest-first, so a contact-tier row left in place will keep overriding a workspace-tier correction.

3. Remove or retire knowledge sources that repeat the same detail.

   Result An answer grounded in a knowledge source is not changed by editing memory.

4. If the person should not be contacted again, record a block rather than deleting them.

   Result A block is a memory row that holds across channels and future conversations; deleting the record removes the very evidence that they asked not to be contacted.

Questions#

Related#

• Files and data in Connect
• Relationships in Connect
• Memory in Connect
• Security and isolation
• Three independent layers of tenant isolation
• Escalating a complaint, end to end