Tenants

What a tenant is

A tenant is a customer on the platform. It owns one or more boundaries, and it owns the people and single sign-on those boundaries share:

• People. Only members of a boundary's tenant can be given a role in it. The exceptions are a workload identity from another tenant that a boundary trust admits, and any principal a platform administrator assigns; a user from another tenant assigned that way becomes a guest of this one. See Members and tenants.
• Single sign-on. Email domains and identity providers are configured per tenant — see Single sign-on.
• The identity provider's organization. On installations that use the identity provider's organizations, which is the default, each tenant has one, and it carries the tenant's members, domains and identity providers.

The platform keeps no separate record of tenants, and a tenant has no name. A tenant exists because a boundary belongs to it, which is why the portal describes a tenant by the boundaries it owns and a short form of its ID.

One tenant per new boundary

Every boundary is created in a new tenant of its own. When one customer should have several boundaries that share people and sign-in, create them and then move each into the same tenant.

Moving a boundary

A move takes a boundary to a new tenant, containing only that boundary, or to an existing tenant, one that already owns another boundary. It needs boundaries/tenant/admin at the root, which only the Platform Owner role has. The steps are in Move a boundary to another tenant.

What follows the boundary on its own, because it belongs to the boundary rather than to the tenant:

• its role and deny assignments, and requests for temporary access;
• the managed identities and service accounts created in it.

What the move carries across:

• The target tenant gets its organization in the identity provider if it has none yet, when organizations are in use. If the identity provider cannot be reached, the move goes ahead and the organization is created later by the platform's regular organization sync.
• People with access join the target tenant: everyone who holds a role in the boundary, or has active temporary access, on the boundary or anything inside it. Someone who can no longer be added, such as a user deleted from the identity provider whose assignment remains, is counted as skipped.
• The boundary's groups are marked as belonging to the target tenant.
• Open invitations to the boundary now make the person a member of the target tenant when they accept.

The source tenant is left as it was: its members, single sign-on and organization stay, because the customer may still own other boundaries there.

When a move stops partway

A move carries the people and groups across first and records the boundary's new tenant last, so a boundary never names a tenant its people have not reached. If a step fails, the boundary stays on its old tenant, the move reports why, and repeating it completes the work: a repeated move to a new tenant continues with the same new tenant instead of creating a second one. A boundary that is being deleted cannot be moved.

After a move

The rest of the platform keeps the boundary-to-tenant mapping in a cache for up to five minutes, so tenant checks elsewhere follow a move within five minutes.