Best Practices for Managing Public Domains in a B2B Organization Model
Hello 👋
I'm building a B2B solution where each client gets their own organization based on their domain (e.g., client.com). The idea is to automatically create a new organization for each detected domain.
Problem:
Some end users sign up with public email domains (gmail.com, yahoo.fr, etc.).
Questions:
How can I handle these users without overcomplicating the architecture?
Is there a reliable way to distinguish public domains from business domains?
Are there any best practices in ZITADEL for this B2B + public user scenario?
Possible Approaches:
Create a default "Public" organization for users with public domains.
Create an organization per public domain.
I’d love to hear your thoughts and best practices. Thanks for your help! 🙏
8 Replies
hi @Shengael thanks for yore question, let me look into this
hi @Shengael from what I understand, do you want to create a new org based on a new domain being detected,yes?.
Hello 👋
I'm working on a B2B solution where each client gets their own organization. Organizations are an internal concept used to manage configurations more easily and transparently—clients are not aware of them.
Two possible approaches:
1️⃣ Organization per domain (current approach)
A new organization is created for each detected domain (e.g., client.com).
Problem: Users signing up with public domains (gmail.com, yahoo.fr, etc.) cause unnecessary organizations to be created.
Questions:
How can we efficiently handle these users without overcomplicating the architecture?
Is there a best practice in ZITADEL to distinguish public vs. business domains?
2️⃣ Organization per client
Each client has a single organization, grouping all its users.
In this approach, if a user signs up with a @gmail.com email, it's not an issue because they will be correctly routed to their company's organization.
The real problem: When a user is already linked to a company and later moves to another company while keeping the same email, we currently have no way to transfer them to the new organization.
Blocking issue: We cannot move users between organizations in ZITADEL.
Questions:
Is user migration between organizations planned?
If not, what are the best alternatives to handle this scenario while preserving as much user data as possible (e.g., login history, activity logs, etc.)?
Since organizations are just an internal structuring mechanism for us, we’re looking for the best way to keep things clean and efficient.
I’d love to hear your thoughts on this! Thanks 🙏
Hi @Shengael thanks for getting back with more details/clarifications, I will check it with my team.
hi @Shengael I think this might help
1️⃣ Organization per domain
I think you can leverage the benefits of Domain Discovery In Zitadel this should eliminate the problem of public vs business domains.
2️⃣ Organization per client
I can check internally how to move between organizations as we might have a custom B2B solution that we provide. But for that, I have to check with my team.
I have one more suggestion for problem 1️⃣ but I'd discuss it with you if the above doesnt helps. I just dont want you to get overloaded with more information 😄 , please give it domain discovery a read and see if it helps. But Writing down this message already so I know I might have to followup or else I'd forget .
Thanks again for your help! I’d like to share a bit more context to clarify our use case:
We’re building a B2B solution with a centralized authentication system. The goal is to offer our clients a smooth and secure login experience, including the ability to sign in using their own Identity Provider (IdP).
User invitation workflow:
- An admin invites the first user for a given client.
- During the invitation, the admin provides a CRM Account ID.
- This user can then invite their colleagues, who will automatically inherit the same CRM Account ID. User context: - Users don’t sign up themselves.
- They are invited manually through an admin portal.
- This portal doesn’t manage the concept of organizations; it only handles user management. On the ZITADEL side, we’re considering two approaches: Solution 1 – Based on email domain:
When a user is invited, we could:
- Create the user in a default organization,
- Then, based on their email domain:
- Create a new organization if it’s a corporate domain,
- Or keep the user in the default organization if it’s a public domain (e.g., gmail.com, yahoo.fr, etc.). Limitations with this approach:
- We don’t have a reliable way to distinguish public from private domains.
- Domain Discovery could help at login time, but not during user creation, so it doesn’t fully solve our challenge. Alternative 1.1:
We could create a single default organization to group all users initially.
Then, only if a client wants to configure an IdP, we create a dedicated organization and move relevant users into it.
But this still depends on the ability to move users between organizations. Solution 2 – Based on client account identifier (preferred approach):
We already have a CRM Account ID available when a user is invited. This would allow us to:
- Create a dedicated organization per client if needed,
- Create the user in ZITADEL,
- And assign them to the correct organization using that identifier. But it depends heavily on being able to move a user from one organization to another.
If that’s possible and supported (even via API or an internal flow), it could unlock everything for us. If your team has suggestions or details about moving users between orgs, I’d love to hear more!
And happy to hear your third idea too if Domain Discovery doesn’t fully fit my use case. Thanks again! Hi again! Just wanted to give a bit more context to emphasize why this topic is important to us. We’re a company planning to migrate around 15,000 users from our existing admin portal into ZITADEL. Before doing so, we want to make sure we’re using the right structure and approach, especially regarding how to manage organizations and assign users correctly. We're happy to jump on a call if that makes things easier to discuss. Thanks again for your time! @Rajat
- During the invitation, the admin provides a CRM Account ID.
- This user can then invite their colleagues, who will automatically inherit the same CRM Account ID. User context: - Users don’t sign up themselves.
- They are invited manually through an admin portal.
- This portal doesn’t manage the concept of organizations; it only handles user management. On the ZITADEL side, we’re considering two approaches: Solution 1 – Based on email domain:
When a user is invited, we could:
- Create the user in a default organization,
- Then, based on their email domain:
- Create a new organization if it’s a corporate domain,
- Or keep the user in the default organization if it’s a public domain (e.g., gmail.com, yahoo.fr, etc.). Limitations with this approach:
- We don’t have a reliable way to distinguish public from private domains.
- Domain Discovery could help at login time, but not during user creation, so it doesn’t fully solve our challenge. Alternative 1.1:
We could create a single default organization to group all users initially.
Then, only if a client wants to configure an IdP, we create a dedicated organization and move relevant users into it.
But this still depends on the ability to move users between organizations. Solution 2 – Based on client account identifier (preferred approach):
We already have a CRM Account ID available when a user is invited. This would allow us to:
- Create a dedicated organization per client if needed,
- Create the user in ZITADEL,
- And assign them to the correct organization using that identifier. But it depends heavily on being able to move a user from one organization to another.
If that’s possible and supported (even via API or an internal flow), it could unlock everything for us. If your team has suggestions or details about moving users between orgs, I’d love to hear more!
And happy to hear your third idea too if Domain Discovery doesn’t fully fit my use case. Thanks again! Hi again! Just wanted to give a bit more context to emphasize why this topic is important to us. We’re a company planning to migrate around 15,000 users from our existing admin portal into ZITADEL. Before doing so, we want to make sure we’re using the right structure and approach, especially regarding how to manage organizations and assign users correctly. We're happy to jump on a call if that makes things easier to discuss. Thanks again for your time! @Rajat
hi @Luis VALDEZ apologies for the late responses, I will get back to you today.
hi @Luis VALDEZ thank you for the detailed POC, I am tagging @Raccine for next steps 🙂
Hey there @Luis VALDEZ! Thanks for reaching out - I've sent over a friend request so that I can directly message you with more information! ☺️
Unknown User•5mo ago
Message Not Public
Sign In & Join Server To View