-
Notifications
You must be signed in to change notification settings - Fork 499
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Co-authored-by: victoria <[email protected]>
- Loading branch information
1 parent
53f71d3
commit 976af9a
Showing
1 changed file
with
5 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,11 +5,11 @@ description: Learn how to architect your application to create organizations on | |
|
||
In some cases, you may want the onboarding process for your app to include creating an organization on the user's behalf. This could be beneficial for several reasons, such as: | ||
|
||
- You would like your users to be manually onboarded by sales staff, who send an invite to join via an organization created for them. | ||
- You'd like your users to be manually onboarded by sales staff who will send invites to join via an organization created for them. | ||
- Your app only makes sense if the user is part of an organization, so you want to create the organization on their behalf as part of onboarding. | ||
- You would like to have an 'admin account' that has access to all organizations across your app and can achieve this by creating an organization for the user with an admin account, rather than allowing the user to create their own organization. | ||
- You'd like to have an "admin account" that has access to all organizations across your app and can achieve this by creating an organization for the user with an admin account, rather than allowing the user to create their own organization. | ||
|
||
If this aligns with your use case, this guide will walk you through architecting your application to avoid unexpected rate limits or billing issues, which can be a common problem when creating organizations on behalf of users. | ||
If this aligns with your use case, this guide will walk you through architecting your app to avoid unexpected rate limits or billing issues, which can be a common problem when creating organizations on behalf of users. | ||
|
||
## Recommended: require users to create orgs during onboarding | ||
|
||
|
@@ -30,9 +30,9 @@ Although it may seem like a reasonable option, it's strongly recommended not to | |
|
||
Let's walk through an example to see why. | ||
|
||
Imagine you have an admin account configured to create organizations on a user's behalf during onboarding and then send an invitation to the user to join the organization. When the user accepts the invitation, the organization will have their account plus the admin account in it. At that point, the organization has two monthly active users (MAUs), which makes it a **billable** organization. All [Clerk plans](https://clerk.com/pricing) come with 100 active organizations included for free, but over that limit, organizations are billed at $1 per month. In this case, for every user that is created in your app, they have an active organization automatically, because of the fact that the admin account is also in the organization. This tends to result in much higher costs than if users' organizations are created without an admin account included, since orgs with only one active user are not billable. Additionally, it's generally a nicer experience for users not to have extra admin accounts in their organizations. | ||
Imagine you have an admin account configured to create organizations on a user's behalf during onboarding and then sends an invitation to the user to join the organization. When the user accepts the invitation, the organization will have their account plus the admin account in it. At that point, the organization has two monthly active users (MAUs), which makes it a **billable** organization. All [Clerk plans](https://clerk.com/pricing) come with 100 active organizations included for free, but over that limit, organizations are billed at $1 per month. In this case, for every user that is created in your app, they have an active organization automatically, because of the fact that the admin account is also in the organization. This tends to result in much higher costs than if users' organizations are created without an admin account included, since orgs with only one active user are not billable. Additionally, it's generally a nicer experience for users not to have extra admin accounts in their organizations. | ||
|
||
If you have an architecture scenario that isn't covered here or feel that it's critical to create organizations using an admin account, reach out to [[email protected]](mailto:[email protected]) for help thinking through a suitable solution. | ||
If you have an architecture scenario that isn't covered here or feel that it's critical to create organizations using an admin account, contact [[email protected]](mailto:[email protected]) for help. | ||
|
||
## Grant a user access to all orgs | ||
|
||
|