Share a record with a colleague

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.

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#

Related#

• Security and isolation
• Hand a conversation to a colleague
• Inviting your team
• Relationships in Connect
• Three independent layers of tenant isolation
• Account and access