āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā ā š shadcn/directory/clerk/clerk-docs/guides/how-clerk-works/multi-tenant-architecture ā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā
ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā
There are several ways to model how users and organizations fit into your application. The 3 scenarios that will be covered in this guide are:
We will share some of the common characteristics of apps in each scenario as well as the level of support for these features in Clerk.
B2C companies focus on selling products or services directly to consumers. Some popular examples are Netflix, Headspace, and Spotify. Clerk supports the B2C user management model out-of-the-box, with little-to-no configuration.
In a B2C scenario, applications generally share the following characteristics:
example.com or app.example.com)[!NOTE] In the B2C scenario, organizations are generally not necessary since users that sign up to your application typically do not exist as part of a team, organization, or workspace.
B2B companies sell to other businesses. Some examples include: GitHub, Vercel, Salesforce, Sentry, and Clerk.
In the B2B model, multi-tenant SaaS applications generally leverage organizations (sometimes called teams or workspaces) to manage users and their memberships. This approach allows for control over what resources users have access to across different organizations based on their roles.
Oftentimes such applications will also allow users to create personal accounts that are separate from other organizations. For example, GitHub allows users to create repositories under their own personal account or an organization they are part of.
The user pool for multi-tenant, SaaS applications will generally fall into one of two categories:
[!NOTE] Clerk supports the shared user-pool model for B2B scenarios which will be discussed in this section. The isolated user-pool model is more relevant in the Platforms scenario which will be discussed in the next section.
B2B SaaS applications with the following characteristics are well-supported with Clerk:
app.example.com)Clerk offers a number of building blocks to help integrate organizations into your application:
<OrganizationSwitcher /> component provides a way for your users to select which organization is active. The useOrganizationList() hook can be used for more control.useOrganization() hook can be used to fetch the active organization.<Protect> component enables you to limit who can view certain pages based on their role. Additionally, Clerk exposes a number of helper functions, such as auth(), and hooks, such as useAuth(), to check the user's authorization throughout your app and API endpoints.The organization's ID should be stored in your database alongside each resource so that it can be used to filter and query the resources that should be rendered or returned according to the active organization.
[!NOTE] Today, Clerk does not currently support the Platforms scenario. We are working on Clerk for Platforms to enable developers building platforms to offer their users Clerk's full range of features and customizability.
In the Platforms scenario, businesses can create multiple, isolated applications with their own user pools, branding, security policies, and limits. Some examples in this scenario are e-commerce platforms like Shopify, e-learning platforms, and mortgage lending platforms.
For example, you may be creating an e-learning platform that allows universities to create courses and enroll students. In this case, each customer would be a university who would have their own set of students, professors, and administrators as their users. Additionally, each university would likely have a custom domain (courses.example.com) with their branding where their users can authenticate and use the platform.
In the e-learning platform scenario, the users of one university should be completely isolated from another university and each university might have its own set of authentication strategies and security policies.
The following are some of the most commonly requested features for the Platforms scenario (Clerk for Platforms):
customer.example.com) or a custom domain (customer.com) for each of your customersā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā ā
āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā