Modeling our hierarchy (Client Org -> Dept -> User)

Hello Identity,

I am willing to build a centralized Identity and Authorization Service (IdP) for a set of three B2B applications we developed internally in our small company.

My requirements:

We serve multiple external client companies (our "Clients").
Each Client has one or more Departments, and users belong to one Department.
Our internal team would manage all user and group administration via the IdP console. Clients are not allowed to administer their own users in the IdP.

How I plan to use Zitadel:

Since we are managing everything centrally, I plan to use a single Organization in the Zitadel instance (our instance's root organization). I will model the Client hierarchy using named groups or roles to maintain separation:

Client Organization: Modeled as a Parent Group (e.g.,
```
ORG:CLIENT_A
```
ORG:CLIENT_A
```
ORG:CLIENT_A
```
ORG:CLIENT_A
).
Department: Modeled as a Subgroup/Role (e.g.,
```
DEPT:CLIENT_A:FINANCE
```
DEPT:CLIENT_A:FINANCE
```
DEPT:CLIENT_A:FINANCE
```
DEPT:CLIENT_A:FINANCE
).

If we have 1,000 clients, this implies we will have at least 1,000 basic client separation Groups/Roles (

ORG:CLIENT_1

ORG:CLIENT_1

ORG:CLIENT_1

ORG:CLIENT_1 to

ORG:CLIENT_1000

ORG:CLIENT_1000

ORG:CLIENT_1000

ORG:CLIENT_1000), multiplied by the number of departments per client.

Is this approach (using thousands of resource-based Groups/Roles, e.g.,
```
ORG:CLIENT_X
```
ORG:CLIENT_X
```
ORG:CLIENT_X
```
ORG:CLIENT_X
) the standard and most scalable way to model a centrally-administered B2B hierarchy in Zitadel?
Zitadel's native multi-tenancy focuses on creating one Organization per client. Since we cannot use this model due to our centralized administration requirement (at least based on my understanding), is the reliance on Groups and Roles the only viable alternative to model the Client hierarchy effectively?

Thank you for your insights!

Ask Inkeep•11/24/25, 2:02 PM

Hi @binajmen, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question.

Ask Inkeep•11/24/25, 2:02 PM

Answer

I wasn't able to find a direct answer about using thousands of role-based groups as a modeling strategy for centrally-administered B2B hierarchies. Here are some relevant sources:

ZITADEL Users (1) : This explains that there is no concept of hierarchies and inheritance based on users or organizations, and recommends structuring users along the smallest unit of groups. You can use organization metadata or your own business logic to describe a hierarchy of organizations or user groups.
Multi-tenancy implementation where users are shared among the organizations. (2) : This discussion suggests creating a separate organization where you put all your users, and then managing the client structure through project roles with organization names, or managing organizations in your application with roles like admin, member, editor added to the project.

Ask Inkeep•11/24/25, 2:02 PM

To learn more, see the sources I considered:

[1] ZITADEL Users
[2] Multi-tenancy implementation where users are shared among the organizations.

Ask Inkeep•11/24/25, 2:02 PM

Feel free to tag @Ask Inkeep with additional questions.

binajmenOP•11/24/25, 2:07 PM

The doc mentions:

There is no concept of hierarchies and inheritance based on users or organizations. This is why we recommend to structure users along the smallest unit of groups. You can use organization metadata or your own business logic to describe a hierarchy of organizations or user groups.

It seems this could match my situation.

I have to let this seek in to grasp how this would be implemented in our case. Is there an example that uses this concept ? @Ask Inkeep

Ask Inkeep•11/24/25, 2:07 PM

Thanks for the follow-up, @binajmen. I'll get back to you soon.

Ask Inkeep•11/24/25, 2:07 PM

Answer

I wasn't able to find a direct example showing how to implement hierarchical structures using metadata or business logic in ZITADEL.

However, based on the available sources, here's what you can work with:

Metadata Approach (1)
You can store arbitrary key-value pairs on Users or Organizations using metadata . This metadata could represent your Client and Department hierarchy (e.g., client_id: "CLIENT_A"client_id: "CLIENT_A", department: "FINANCE"department: "FINANCE") . Metadata can be accessed with the correct scopes or transformed to custom claims using Actions .

No Native Hierarchies
ZITADEL doesn't have built-in hierarchies or inheritance between users or organizations . The recommendation is to structure users along the smallest unit of groups and use organization metadata or your own business logic to describe hierarchies .

Alternative: Multiple Organizations (2)
While you mentioned centralized administration as a constraint, ZITADEL does support delegated access management where you can create separate organizations for each client and still maintain central control (2) (3) . You would grant projects to organizations and manage authorizations centrally (3) .

For a concrete implementation example using metadata to model your hierarchy, I'd recommend clicking the "Ask for help" button to get guidance from a team member who can provide specific implementation patterns for your use case.

Ask Inkeep•11/24/25, 2:07 PM

To learn more, see the sources I considered:

[1] ZITADEL Users
[2] Onboard B2B customers using organizations
[3] Migrate to ZITADEL

Ask Inkeep•11/24/25, 2:07 PM

Feel free to tag @Ask Inkeep with additional questions.