# Share a record with a colleague

Copy the address of the screen you are on and send it. A link is a location inside the application, never a grant: whoever opens it must sign in with Google, and what they then see is decided by which workspace they belong to. Somebody outside the workspace sees nothing, because isolation is enforced in three independent places rather than by hiding the link.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/inbox, #/pipeline, #/data
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/how-to/share-a-record/

## What the link is

Screens in Connect are addressed by route — the conversations screen, the pipeline, relationships, the data grid — and a record is a position within one. Sending a colleague that address takes them exactly where you were, which is the whole feature. It is worth being clear about what it is not.

- **Not a permission.** Nothing about the link authorises anything. It carries no token, and forwarding it does not extend access to the person it was forwarded to.
- **Not a public page.** There is no anonymous view of a record. Sign-in is Google OAuth and there is no password route, so an unauthenticated visitor has nowhere to go.
- **Not a copy of the data.** The recipient reads the live record, so what they see reflects any change made between your sending it and their opening it.
- **Not cross-workspace.** A member of another workspace who opens it is refused by the same layers that refuse any cross-tenant read.

## Sharing one, and confirming it landed

1. Open the record you mean — the person, the deal, the conversation, the call — and take the address of the screen.
   - Result: You have a location that reopens to the same place.
2. Check the colleague is a member of this workspace before you send it. If they are not, the link is not the missing piece; membership is.
   - Result: You avoid the common exchange where somebody reports a broken link and the real answer is that they were never in the workspace.
3. Send it with one line of context saying what you want them to do. A link on its own is a location, not a request.
   - Result: The recipient knows whether they are reading, deciding, or acting.
4. If the job is genuinely theirs, create a follow-up on the `task` channel instead of relying on the message being seen.
   - Result: The work is dated, carries a reason and sits in a queue that is worked — rather than in somebody's chat history. No drain ever sends a `task` follow-up, so it can only be closed by a person.
5. Ask them to confirm what they can see.
   - Result: That is the verification, and it distinguishes the three failure modes below faster than any amount of checking from your side.

## Why an outsider sees nothing

Isolation here is not one check that could be forgotten. A request is filtered three times: an allowlist in the middleware decides whether this session may call this path at all, the workspace kernel filters every query the application makes, and the database applies row-level security underneath both. Sharing a link cannot bypass any of them, which is why the honest answer to "can I send this to our accountant" is "only if they are in the workspace".

One deliberate consequence surprises people. Website enquiries addressed to JBRH sit outside every workspace by design, on the platform's own control-plane table. A customer who cannot find such an enquiry in their workspace is seeing isolation working, not a fault.

> **Note** A written relationship summary has names scrubbed on the way out. If you are circulating a summary rather than a record, that scrubbing is the thing standing between a shareable overview and somebody else's personal data — do not defeat it by pasting names back in.

## When the link does not work for them

**They land on a sign-in screen** — Expected. Sign-in is Google OAuth only. After signing in they should arrive where you were.
**They sign in and see an empty or refused screen** — They are in a different workspace. The link is fine; the membership is the issue.
**They see the screen but not the record** — Check that the record is what you think it is — a person can hold several identities and you may be looking at a different one of the same human.
**It worked for them yesterday and not today** — Signing in as somebody else ends the session it replaced on that browser, and only that browser. A shared machine explains most of these.
**They can see it but cannot act on it** — Acting needs the relevant permission — approving a send, for instance, needs permission to send on that channel. Viewing and deciding are different rights.

## Questions

### Can I share a record with someone outside the business?

Not by link. There is no anonymous or guest view. What you can share externally is content you deliberately extract — an export, a document, a summary — and that is a decision about data leaving the workspace rather than a link.

### Does opening a shared record show up anywhere?

Actions are recorded with the person who took them; the decision log answers who released, approved or changed something months later. Treat the trail as an account of decisions rather than a page-view log.

### Is the link stable if the record changes?

It points at the record, so renaming a person or moving a deal between stages does not break it. Merging two duplicate people is the case to watch: the surviving record is the one to share afterwards.

### What is the difference between sharing and handing over?

Sharing shows somebody a record. Handing over transfers the work, which is a follow-up with a reason and a due date — and is documented separately, because the two get confused and the conversation then sits with nobody.

## Related

- [Security and isolation](https://connectbyjbrh.com/docs/security/)
- [Hand a conversation to a colleague](https://connectbyjbrh.com/docs/how-to/hand-over-to-a-colleague/)
- [Inviting your team](https://connectbyjbrh.com/docs/getting-started/inviting-your-team/)
- [Relationships in Connect](https://connectbyjbrh.com/docs/relationships/)
- [Three independent layers of tenant isolation](https://connectbyjbrh.com/research/three-layers-of-isolation/)
- [Account and access](https://connectbyjbrh.com/docs/account/)

## What this page is based on

- docs-source/sources/GENERAL.md §2 — the three isolation layers
- docs-source/sources/GENERAL.md §10 — Google OAuth only, session replacement
- docs-source/sources/CHANNELS.md §5 — the scrubbed relationship story
- docs-source/sources/CHANNELS.md §7 — website enquiries outside every workspace