Better Multi-Tenant Support for Language and Members [In Umbraco Backoffice]

[Girish-kl33]

Umbraco already works really well for multi-tenant setups in many areas. For example, we can manage hostname and culture per tenant, and on the user side we have good control with permissions and start nodes. That gives a lot of flexibility when different tenants are managed in the same Umbraco instance.

But there are still a couple of areas where multi-tenant support could be even better.

1. In the Language section, it would be really helpful if we could set a default language for each tenant. Right now, the only option is more of a workaround — removing the global default language and then setting the culture on the nodes themselves. It works, but having tenant-level default language support would make things much easier and cleaner.

2. In the Member area, User have less control compared to Content, and Media. For users, we can define start nodes and permissions, which is great for multi-tenant management. It would be very useful to have something similar for member groups — for example, being able to limit which member groups are visible or manageable based on the tenant.

This would be especially important when working with sensitive data, where stronger separation and better security are needed between tenants.

Overall, these two improvements would make Umbraco’s multi-tenant support more complete and much easier to manage in real-world projects.

[Afreed-cp]

Hi Girish,

1. Default Language per Tenant

In most Umbraco setups, a 'tenant' is essentially just a root node or a document type. Since languages and defaults are currently handled at the system level, I’m curious about the feasibility of moving this to the node level. If we set a default language on an individual node, it might create conflicts with how the dictionary and 1-to-1 multilingual mapping work globally. It feels like this would require a significant shift in how Umbraco handles culture-variance.

2. Member Groups and Start Nodes

Regarding the Members area, we have to remember that Members and Users serve completely different purposes. Members don't access the backoffice or interact with the 'tree' in the way Users do.
The concept of a 'Start Node' for a Member seems redundant because Member protection is already handled via 'Public Access' on the nodes themselves or through role-based checks in the code

it feels like these aren't necessarily 'missing' features, but rather specific implementation requirements that face significant architectural hurdles.

[Girish-kl33]

Thanks for your detailed thoughts @Afreed-cp.

I think there might be a bit of a gap in context, so let me clarify the scenario I had in mind.

For example, there is one company XXX manage multiple websites across different countries/business units, all within the same instance.

• Each site (tenant) can have its own inters, editors & admins [users]
• Some sites may act as web apps with frontend member login
• Each site may also have its own admins[User] who need to manage their own members[memebr Group]

From a security and separation standpoint, this creates additional requirements:

• Site-specific admins should only see and manage members متعلق to their own tenant
• Member groups may need to be scoped or limited per tenant to avoid overlap or accidental access
• In practice, we often end up building custom solutions (e.g., hiding sections, creating separate member management areas) to achieve this isolation

Regarding languages, the need comes from similar complexity:

• Each site can target a different country/language
• We still need to maintain a global default language for Umbraco
• But having a tenant-level default language would simplify content workflows and avoid workarounds like setting culture manually on nodes

I completely agree that these are not requirements for every project. However, in scenarios where a single backoffice manages multiple independent sites with different teams, languages, and member bases, these limitations become more apparent.

So from my perspective, it’s less about missing features in general, and more about improving support for more advanced multi-tenant use cases.

Hope this gives a clearer picture of the context I was referring to 🙂

[Afreed-cp]

@Girish-kl33

I think you wants to be able to go into a User's settings (the backoffice editor) and say: "This User is allowed to see/edit Members who belong to 'Group A' but not 'Group B'."

I’m still not sure if making the Member section 'Permission-aware' in this way is the right move for the Core architecture, or if it stays in the realm of a custom implementation for enterprise needs.

[Girish-kl33]

Thanks for the clarification.

For the Users side, Umbraco already has options like Content start nodes and Media start nodes. In the same way, having a way to assign or limit Member Groups for specific backoffice users would really help in this scenario. I do not think this would be too difficult a change for Umbraco, and I strongly believe it is something necessary for multi-tenant setups.

For the language side, I completely understand that, with the current Umbraco structure, introducing a default language at the node or tenant level is much more complex. It could conflict with how dictionary items and culture-variant content are handled globally, so it would likely need a deeper architectural change.

That said, there may still be other ways to support this better — for example at role level, user level, or even as an additional option in the Languages section, where you could define default or mandatory languages for a specific root level node. I think those kinds of possibilities are definitely worth considering.

[Girish-kl33]

The language part is more complex, but the Member Group use case is a separate and much simpler discussion.

To keep this topic clear and focused, I’ve started a separate discussion specifically for the Members section here:
#22251