Users and Organizations in Multi-Tenant SaaS
--
When designing a multi-tenant Software-as-a-Service from scratch, there are decisions to make at the very beginning. One such decision is the relationship between users and organizations. In this blog post, we will present multiple approaches to the design of the users and organizations model.
First, we must define the relationship between users and organizations. The most straightforward approach is to map each user to a single organization. This approach is standard if we identify users by their work email, and there can be exactly one SaaS organization per company.
However, there are scenarios where a user may belong to more than one organization. For example, at GitHub, every user has their organization and maybe a member of another organization. Another example is a contractor with multiple clients.
When a user belongs to multiple organizations, the user needs to remember one set of credentials. If these credentials are compromised, more than one organization is affected. However, if additional precautions such as two-factor authentication are in place, this risk is much lower.
Another difference between these approaches is a legal one. When all users belong to the same organization, the organization must accept a single EULA to cover all their users. Otherwise, each user must sign a user-oriented EULA, and each organization must sign an organization-oriented EULA instead.
When integrating single-sign-on with a customer, the user can only belong to the customer’s organization.
The next step is to define the sign-in and sign-up experience.
The design of the users and organizations model affects the sign-in and sign-up experience. The sign-in/up page can be either specific to an organization or — a generic one.
An organization-specific sign-in/up page is perfect for enabling branding before sign-in. For example, at Slack, each organization (workspace) has a subdomain.
A generic sign-in page may deduce the organization(s) of the user. The sign-in page can either ask the user for the organization or infer it from the username. For example, the AWS root account email defines the AWS account.
It is also possible to either show an organization-agnostic dashboard (as done at GitHub) or show the last organization the user works at (as done at MongoDB Cloud).
In this blog post, we presented various approaches to the relationship between users and organizations. There is no correct approach for all SaaS designs. We might need to provide multiple methods in the same SaaS. It highly depends on business model needs and the type of users involved.
