Multi-Tenancy Entity Model

Wristband enforces a strict tenancy architecture. Each tenant in Wristband has a unique tenant identifier ("tenantId"). Users must always be assigned to a tenant, and a single user cannot belong to multiple tenants, ensuring complete isolation and tenant-specific control over users.

Tenants and User Uniqueness

There are 3 fields within User entities that must be unique within a tenant:

• email
• username
• externalId

User Uniqueness in a Tenant

Users in the same tenant can have the same email, username, and externalId values as long as they are provisioned in different identity providers.

For example, if Tenant A has a user with email [email protected] in the Wristband identity provider, creating another user with the same email in the same provider will fail due to a uniqueness violation.

However, creating another user with the same email in the Google Workspace identity provider will succeed, as they are distinct entities.

User Uniqueness Across Tenants

Users with the same email can exist in different tenants, even within the same identity provider. For instance, creating a user with [email protected] in Tenant B's Wristband identity provider will succeed, even if it exists in Tenant A.

Types of Tenants

In Wristband, there are three different types of tenants: STANDARD, GLOBAL, and STANDALONE. The tenant type can be chosen at the time of tenant creation, but keep in mind that type is immutable.

Standard Tenants

Standard tenants are used to represent organizations within a multi-tenant application. Each standard tenant has its own login page that is fully customizable. Users belonging to standard tenants must log in to your application using their tenant-specific login page. Users are able to discover which standard tenants they belong to by going through the tenant discovery flow.

Standard tenants will see both application-specific and tenant-specific language on the Wristband-hosted Tenant Login Pages and in the transactional email templates.

Global Tenant

Global tenants are meant to store consumer users that are not associated with an organization. Only one global tenant can be created per application.

🚧

Global Tenant Differences

Global tenants are excluded from tenant discovery results when a user enters an email address on the Tenant Discovery Page that is associated with multiple tenants. They also cannot have Enterprise External Identity Providers because a 1-to-1 scoping to an organization is not possible.

All users of a global tenant share the same Tenant Login Page. For global tenants, any hosted pages and transactional emails will offer a consumer-like login experience by removing tenant-specific language from the UI. Typically, users will navigate directly to the Global Tenant Login Page URL when accessing your application.

You can also enable the Login Workflow Policy to display a "Log In with Your Organization" link on the Global Tenant Login Page which will send users to the Tenant Discovery Page. This provides a seamless hybrid experience for both consumer and organization-specific needs throughout your application.

Stand-alone Tenants

Stand-alone tenants can be used to provide a completely white-labeled experience. There's no restriction on the number of stand-alone tenants that can be created for an application.

For stand-alone tenants, any language regarding the application is removed from all hosted pages and transactional emails. Only the tenant-specific information will be displayed. Likewise, any links that allow for changing to a different Tenant Login Page will be removed.