Shared Functionality Across Tenants¶

Put functionality that cuts across tenants into one shared tenant. Give a functionality its own tenant only when it needs a different audience, different admins or a different policy.

The Problem¶

Regular tenants are vertical: each one is a separate customer or organization with its own users, admins and data. Some functionality is horizontal and spans them, for example shared documents that people from several tenants work on, as opposed to each user's personal documents.

flowchart BT
    subgraph S["Shared tenant"]
        SD["Shared documents"]
        SO["Other shared functionality"]
    end
    A["Tenant A<br/>personal documents"] --> S
    B["Tenant B<br/>personal documents"] --> S
    C["Tenant C<br/>personal documents"] --> S
    D["Tenant D<br/>personal documents"] --> S

Each vertical tenant keeps its users, admins and personal documents. Its users also become members of the one shared tenant.

What a Tenant Is¶

A tenant is a logical security and administration boundary: who is in it, who administers it, which permission sets and policies apply. It says nothing about where the rows physically live or how many users it holds.

Microsoft 365 shows the same split:

Personal and shared content inside a company live in one tenant: each user's OneDrive is a personal site, and team documents live in SharePoint sites and Teams in the same tenant.
All personal Microsoft accounts belong to one logical "consumers" tenant, while the accounts and their data are spread across separate systems and datacenters.
Work across tenants uses guest accounts (B2B) and shared channels.

Options¶

Option	How it works	Fits	Cost
Specialized tenant	Shared functionality lives in its own tenant; users join it through membership in its groups	Horizontal shared areas	Works today, no schema change; the app passes that tenant's id when it calls functions for that functionality
Containers inside a tenant	Items owned by a user and shared through resource-level ACL	Personal vs shared within one tenant	Works today; does not cross tenant boundaries
Org layer above tenants	A parent org whose features span its child tenants (Slack Enterprise Grid, Atlassian organizations)	Many shared tenants that need inheritance	Not supported: needs a tenant hierarchy, inherited permissions and cross-tenant queries

One Shared Tenant by Default¶

Tenants follow who administers something and who is in it, not what feature it is. In this model a tenant brings:

its own members (through groups, which are tenant-scoped)
its own admins and owners (ownership)
its own permission sets and groups, including external group mappings
its own audit scope and cross-tenant visibility rules

If two shared functionalities have the same audience and the same admins, separate tenants only duplicate that setup:

every user added to N tenants
group mappings maintained N times
N copies of similar permission sets
the app juggling N tenant ids

Inside one shared tenant, the functionalities are kept apart with what already exists:

Permissions -- documents.* and calendar.* live in one global hierarchy.
A permission set per functionality -- for example "Shared Docs Editor" and "Calendar Viewer" (auth.create_perm_set).
Groups -- decide who gets which permission set. With an external group mapping (auth.create_user_group_mapping), a provider group grants access without syncing members.
Resource-level ACL -- controls sharing of individual items (auth.assign_resource_access, auth.deny_resource_access).

Tenant 1 is not the shared tenant

Tenant 1 is the admin tenant with cross-tenant visibility through read_all_* permissions. Keep shared end-user functionality in its own regular tenant so that membership in it grants nothing administrative.

When to Split Off a Separate Tenant¶

Give a functionality its own tenant when any of these holds:

Different audience -- for example, external partners use one functionality and must not see who is in the others.
Different admins -- someone should manage one functionality without admin rights over the rest.
Different policy -- retention, compliance or MFA rules that apply to only one part.
Separate lifecycle -- the whole thing may be deleted or handed over in one go.

Personal Documents¶

Personal documents stay in the user's own tenant as resources they own, shared through resource-level ACL. That is the OneDrive model. A tenant per user would multiply tenants for no gain.