# Answering a customer's data request

Everything a workspace holds about one person is reachable from that person's own record and exportable from the record sheets as CSV. What cannot be produced is anything outside the workspace — including website enquiries addressed to the operator, which deliberately belong to no workspace. Whether a request must be answered at all stays a decision for the business.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/data, #/timeline
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/data-request/

## What is actually held

| Source | What it holds | How it is produced |
|---|---|---|
| The Person record | Names, identities on each channel, company, lifecycle stage | The relationship screen; identities are listed rather than merged into one field |
| The timeline | Every exchange on every channel, in order | The person's own view — this is the fullest single answer to what do you hold about me |
| Conversations and calls | Messages, transcripts, summaries and outcomes | Open from the timeline; calls carry their own transcript and summary |
| Memory | What Connect learned or was told, at four tiers | The memory viewer, which shows every tier including the empty ones |
| Follow-ups, cases, opportunities | Commitments, support history, deals | Their own screens, and as sheets in the record grid |
| Files | Documents attached to the relationship, with their versions | The file list on the record; versions are kept rather than overwritten |
| The record grid | Thirteen sheets over the same records | Filter to the person and export CSV; formulas are neutralised on the way out |

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.

> **Note** Nothing on this page is a statement about a law, a regulation or a certification. It describes what the software can produce. Whether a request must be answered, within what period, and by whom, is the business's own obligation and its own judgement.

## 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.

> **Careful** Deleting a person to satisfy a do-not-contact request is the common mistake here. It destroys the suppression along with the record, and the next time that address appears it looks like a new contact.

## Questions

### Can a customer get their data directly from Connect?

No. There is no self-service portal for a business's customers, and there deliberately is not: the relationship is between the business and its customer, and identity checks belong with the business. Connect gives the business what it needs to answer.

### Does exporting from the record grid change anything?

No. Export is a read. Editing in the grid is a different matter — every change there goes through the service that owns the record, so the grid cannot become a second, divergent store.

### Is a call recording part of what can be produced?

Call recording is not enabled on the live carrier, so there is no recording to produce. What exists for a call is its transcript, its summary and its outcome, and those are on the person's record like any other exchange.

## Related

- [Files and data in Connect](https://connectbyjbrh.com/docs/files-data/)
- [Relationships in Connect](https://connectbyjbrh.com/docs/relationships/)
- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)
- [Security and isolation](https://connectbyjbrh.com/docs/security/)
- [Three independent layers of tenant isolation](https://connectbyjbrh.com/research/three-layers-of-isolation/)
- [Escalating a complaint, end to end](https://connectbyjbrh.com/docs/workflows/complaint-escalation/)

## What this page is based on

- Connect source pack §9 — the record grid, its thirteen sheets and CSV export (`docs-source/sources/GENERAL.md`)
- Connect source pack §2 — isolation enforced three times (`docs-source/sources/GENERAL.md`)
- Connect source pack §7 — website enquiries belong outside every workspace (`docs-source/sources/CHANNELS.md`)
- Connect capability registry (`docs-source/facts.py`) — `call_recording` is foundation and not enabled on the live carrier