What Happens to a Shared Link When the Person Who Sent It Leaves?
Nobody asks this question until the Monday it matters. Somebody has left, and out there in the world are live links to proposals, contracts and specifications that they created, sitting in inboxes belonging to your clients.
What happens to those links is a design decision somebody made on your behalf, and there are three common answers. Two of them are bad.
The three answers, and why two are wrong
- Everything they shared dies with the account. Tidy, defensible on a whiteboard, and unacceptable in practice. Your client is not party to your staffing decision. Breaking their link — possibly mid-negotiation, possibly the day the contract is being signed — turns an internal event into an external one, and it is your problem for the following week rather than theirs.
- Everything silently transfers to somebody else. Worse in a subtler way. If a departure quietly rewrites who owns a share, then removing somebody from a workspace becomes a mechanism for acquiring their work — and their read data, including who read what and when. That is a privilege escalation with a friendly name.
- The links keep working, and somebody is told they are now unowned. This is the only answer that respects both the client and the person who left.
What actually happens in Quixli
The rule the departure follows is a single sentence: access moves with the workspace, ownership does not move at all.
- The links stay live. A departing member’s active shares are not touched. The client who has your proposal open in a tab does not find out about your staffing.
- The documents stay with the organisation. Nothing is deleted and nothing is transferred to another person. The work belongs to the workspace it was done in.
- Access ends immediately. The moment the membership is marked removed, that person can no longer reach any of it — not the documents, not the shares, not the read data. Their next request resolves to their own personal workspace instead.
- Attribution survives. Every visit, every captured address, every share keeps its original owner. The record still says who did the work, and a former member is displayed as a former member rather than as a blank.
- Invitations they had sent are revoked. A pending seat offered on the authority of somebody who has left is not a seat you want honoured.
- Reading sessions that were in flight are left to finish. Cutting them short would not remove anybody’s access; it would only put a wrong number in a report. The measurement closes itself normally.
The cost, stated rather than hidden
Choosing not to break links has a consequence, and it is the reason most tools pick one of the bad answers instead: you now have live client-facing links whose owner is no longer in the building. That is a real management problem and it does not solve itself.
So it is surfaced as a list. A workspace admin can see every share whose owner is not an active member — people who left, people who were suspended, accounts that were deleted — with each row saying which of those it is. That list is the work item, and looking at it belongs in your offboarding checklist rather than in your memory.
There are two things you can do with a row on it.
- Reassign it. Responsibility for the link moves to somebody who is still here. They see the share and everything it produces from that point on. What they do not get is the back catalogue: visits and captured addresses recorded before the reassignment keep their original owner, so under the default visibility setting the new owner does not inherit a history they had nothing to do with. Reassignment changes who is responsible, not who did the work — and the previous owner is recorded on the share.
- Revoke it. Close the link. Correct when the relationship is over, when the document is stale, or when nobody is going to pick it up. It ends access without rewriting any history.
Both actions refuse to run against a share whose owner is still active — otherwise "reassign" would be a way to take a colleague’s work sideways while they are sitting three desks away.
What the person who left gets
The other half of a fair departure is that leaving does not mean losing everything you made, and it should not require begging.
A former member can request an export of their own work from the workspace they left: their folders, documents with content, collections, their shares with per-share totals, and the leads those shares captured. The workspace owner approves or refuses it, and no path produces an export without an approval on record.
Two boundaries on that are worth knowing. Approval decides whether, never what: the contents of the export are fixed by the person’s own ownership, not by their old role or by how generous the approver is feeling. And it contains aggregates rather than the individual visit records — a departing salesperson leaves with their work and their own numbers, not with a per-session file describing named clients’ reading habits.
The offboarding checklist
- Remove the membership first. Access ends there, and everything after it is bookkeeping.
- Open the list of shares whose owner is no longer active, on the day, not at the end of the quarter.
- Reassign anything with a live client relationship attached, to the person now holding that relationship.
- Revoke the rest rather than leaving it live because nobody decided.
- Handle their export request rather than ignoring it, and remember they cannot see the workspace to chase you.
- Tell the clients whose relationship changed hands. The link still works; the person does not.
If you are setting a team up rather than dismantling one, sharing a document with your team without losing track of who sent what covers the arrangement that makes this Monday easy instead of hard, and the team workspace is where these controls live.