Add a guide detailing how to create orgs on users' behalf

docs/guides/creating-orgs-for-users.mdx

@@ -0,0 +1,39 @@
+---
+title: Recommended Architecture for Creating Organizations on Users' Behalf
+description: Learn how to architectect your application to create organizations on users' behalf without running into rate limits and billing issues.
+---
+
+In some cases, you may want the onboarding you your application to include the creation of an organization on the user's behalf. This could be for a number of reasons, such as:
+
+- You would like for users to your application to be manually onboarded by sales staff and sent an invite to join via an organization created for them.
+- Your application only makes sense if the user is part of an organization, and you want to create the organization on the user's behalf as part of the onboarding process.
+- You would like to have an "admin account" that has access to all organizations across your application, and can achieve this easily by creating an organization on the user's behalf, rather than allowing the user to create their own organization.
+
+If this sounds like it fits your use case, this guide will walk you through how to architect your application in this way without running into unexpected rate limits or billing issues, which can be a common problem when creating organizations on behalf of users with Clerk.
+
+## Recommended Flow
+
+The recommended approach to ensuring that all users are in an organization is to implement an [onboarding flow](/docs/guides/add-onboarding-flow) in which it's required to create an organization before the user is able to access the application. You can use tools like the [`<CreateOrganization>` component](/docs/components/organization/create-organization) to allow the user to create and name their own organization, or you can use Clerk's [Backend API](/docs/reference/backend-api/tag/Organizations#operation/CreateOrganization) or one of our backend SDKs like the [JS Backend SDK](/docs/references/backend/organization/create-organization) to create an organization on the user's behalf and name it as you'd like.
+
+If you'd like to have the your onboarding flow involve the user being invited to join your app via an email, you can use Clerk's [invitation functionality](/docs/users/invitations) to accomplish this. So the overall flow would look as such:
+
+- User receives an invitation to join your application
+- Upon clicking the invitation, user registers their account and enters the onboarding flow
+- User creates an organization as part of the onboarding flow, and is able to invite colleagues if relevant
+- You now have a user that can access your application and is guaranteed to be in an organization
+
+If you'd also like to enable users to join an existing organization that matches their email domain if one exists, as an alternative to creating a new organization, you can use Clerk's [verified domains](/docs/organizations/verified-domains) feature to accomplish this.
+
+## You'd like admin access to all organizations in your app
+
+The easiest way to grant someone on your team admin access to all organizations in your app is to add them as a member to organization on clerk.com. Through Clerk's dashboard, you can see all of the organizations for each of your apps, and take administrative actions, such as adding or removing members, renaming, or deleting an organization.
+
+If for some reason this is not an option, you can use Clerk's [Backend API](/docs/reference/backend-api) or one of our backend SDKs like the [JS Backend SDK](/docs/references/backend/overview), alongside [roles and permissions](/docs/organizations/roles-permissions) to create a custom admin dashboard through which authorized users can can take adminstrative actions for organizations.
+
+## Not recommended: using an admin account to create organizations for users
+
+Although it may seem like a reasonable option, we strongly recommend against using a single admin account to create organizations on the behalf of users. Generally, this is because it can create unexpectedly high costs due to the way that organizations are billed. Let's walk through an example to see why.
+
+Imagine that you have an admin account that is configured to create organizations on a user's behalf during onboarding, then send an invitation to the user to join the organization. When the user accepts the invitation, their organization has an unneccessary extra admin account in it, and additionally at that point, the organization has two monthly active users (MAUs), which make it a active 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/month/org. This means that 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. Additionally, it's generally a nicer user 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, please reach out to us at [[email protected]](mailto:[email protected]) and we'll be happy to help think through a suitable solution.

docs/manifest.json

@@ -134,6 +134,10 @@
             {
               "title": "Override Clerk interfaces with custom types",
               "href": "/docs/guides/custom-types"
+            },
+            {
+              "title": "Creating Organizations on Users' Behalf",
+              "href": "/docs/guides/creating-orgs-for-users"
             }
           ]
         ]