A collaboration platform adds shared channels between separate customer organisations. What data-boundary problems does this create, and how should authorization be modelled?

Why this breaks the existing model

Multi-tenant systems are usually built on one invariant: a user belongs to one tenant, and data belongs to one tenant. Every query filters by tenant, every cache key is scoped by tenant, and the isolation is enforced structurally.

Shared cross-organisation channels violate that invariant directly. A single conversation now contains messages authored by members of two organisations, each of which has its own retention policy, its own data loss prevention rules, its own compliance exports, its own admins and its own legal obligations.

Every assumption of the form "this record belongs to tenant X" becomes false, and the places that assumption is embedded are numerous and mostly undocumented.

The specific problems

• Whose retention policy applies? Organisation A retains for 30 days; B for seven years. Deleting A's messages destroys B's record; keeping them violates A's policy. The workable answer is that each message is governed by the policy of its author's organisation, with the shared channel being a view over messages that remain individually owned.
• Whose data loss prevention scans? Both, independently, on their own members' content — with the consequence that one organisation may block content the other permitted.
• Whose compliance export includes what? Each organisation exports its own members' messages. An export that includes the other organisation's content is a data leak wearing a compliance label.
• What happens on disconnection? When the relationship ends, each organisation keeps its own messages and loses access to the other's — which requires the ownership model to have been correct from the beginning.
• Who can add members? An admin in A adding a user grants that user access to B's content, so B needs a policy control over who A may add, or the boundary is only as strong as the least careful partner.
• What is visible in search, mentions and profiles? Directory information crosses the boundary and must be limited to what each organisation has agreed to expose.

How to model the authorization

Per-record ownership, not per-container ownership. The channel is a shared context; each message, file and reaction retains its authoring organisation as an immutable attribute, and every policy decision — retention, export, DLP, deletion, legal hold — consults that attribute rather than the container's.

Access is the intersection of two grants: the user's organisation must be party to the connection, and the user must have access within their own organisation. Either side can revoke unilaterally, and revocation must be immediate rather than eventually consistent.

Policy conjunction rather than resolution. Where two organisations' policies differ, the answer is usually the more restrictive applies to the shared surface, with each organisation retaining full control over its own content. Attempting to reconcile policies into a single effective policy produces surprises; applying both and letting the intersection be the outcome is predictable.

The engineering consequence

The tenant identifier can no longer be a filter applied at the edge; it becomes a per-record attribute evaluated throughout. That is a substantial change to caching (keys must include the viewing organisation), search indexing (results filtered per viewer), and every export path.

Retrofitting this into a system built on single-tenant ownership is among the harder migrations in enterprise software, and the reason is that the old invariant is relied upon in places nobody has enumerated — which is why the first step is finding them, not designing the new model.