Per-Record Tenancy

Conventional multi-tenancy assumes a record belongs to exactly one tenant, and containers belong to tenants too. Every query is filtered by tenant identifier at the edge, caches are keyed by tenant, and isolation is structural — which is efficient, easy to reason about, and correct as long as the assumption holds.

Cross-organisation collaboration breaks the assumption. A shared channel, a shared document, a shared project or a shared workspace contains content authored by members of different organisations, each governed by different retention rules, different data-loss policies, different regulators and different administrators.

Per-record tenancy resolves this by making the owning organisation an immutable attribute of each record, so the container becomes a shared context rather than an owner, and every policy decision consults the record.

Why it matters

The alternatives are all bad. Assigning the container to one organisation gives that organisation control over the other's content, which is unacceptable. Duplicating content per organisation creates divergent copies and doubles the deletion problem. Merging the policies into one effective policy produces behaviour neither party expects and cannot be explained to either.

Per-record ownership is the only model where each organisation retains full authority over its own content and none over the other's, which is the property both parties actually require, and it is the property that survives the relationship ending.

Implementation patterns

• Owning organisation stamped at creation and never mutable, on messages, files, comments, reactions and metadata alike — partial coverage is the usual defect, and the uncovered record type is the one that leaks.
• Policy evaluation per record: retention, legal hold, DLP scanning, export inclusion and deletion all consult the record's owner rather than the container's.
• Access as the intersection of two grants — the organisations are connected, and the user has access within their own — with either side able to revoke unilaterally and immediately.
• Policy conjunction on the shared surface: where two policies differ, the more restrictive applies to shared behaviour, which is predictable and explainable.
• Cache keys including the viewing organisation, since the same container renders differently per viewer.
• Search indexes filtered per viewer, not per container.
• A defined disconnection behaviour, decided and implemented before the feature ships: each side keeps its own records and loses access to the other's.
• Controls over who the partner may add, or the boundary is only as strong as the least careful administrator on either side.

Industry example

Slack Connect — shared channels spanning distinct customer organisations — is the widely-discussed instance, and the published material makes the governance problem explicit: each organisation's messages remain subject to that organisation's retention and compliance settings, so the channel is a shared view over separately-owned content rather than a jointly-owned container.

The same structure appears in shared documents across enterprise tenants, cross-company project workspaces, and any B2B collaboration surface — and in each case the difficulty is identical: the product feature is easy and the data governance is the actual engineering.

Failure scenarios

• Container-level ownership retained, so one organisation's retention job deletes the other's records.
• Compliance exports including the partner's content, which is a data leak in the shape of an audit artefact.
• Cache keys omitting the viewer, so one organisation's view is served to the other.
• Search indexes built per container, returning content the viewer may not see.
• Some record types unstamped — reactions, edit history, file thumbnails, link previews — which are exactly where the leak occurs.
• Directory and profile information crossing the boundary by default, exposing more than either party agreed.
• Revocation implemented as eventually consistent, leaving a window after a relationship ends.
• Retrofitting onto a system whose tenant filter is applied at the edge, where the old assumption is relied upon in unenumerated places.

Trade-offs

Per-record tenancy removes the cheapest isolation mechanism available. A single tenant filter at the query boundary is fast, easy to audit and hard to get wrong; per-record evaluation is none of those things, and it must be applied consistently across every path — API, search, export, cache, notification, webhook.

It also complicates performance work: caching becomes viewer-dependent, indexes multiply, and queries that were a simple filter become joins against ownership attributes.

The trade is isolation simplicity and performance in exchange for the ability to share data across tenant boundaries without either party losing governance of their own content. For a product with no cross-tenant sharing, it is unnecessary complexity. For one that has it, there is no simpler model that is actually correct — and the migration cost is a strong argument for choosing it before the feature exists rather than after.

Interview question

"We are adding shared workspaces between customer companies. Tell me who owns a message, whose retention policy deletes it, what each side's compliance export contains, and what happens to all of it on the day they stop working together."