​
Overview

A tenant is the real unit of ownership in Simnet. Every resource belongs to exactly one, quotas are assigned per tenant, and users are granted access per tenant.
Navigation: Organization → Tenants. Titled Tenants, subtitled “Manage organizations, domains and resource limits”.

​
Not a table

Unlike most screens, this one shows a hierarchy rather than a column table, because tenants nest. A stats bar sits above a tenant tree, and a view switcher offers three layouts: Search matches tenant name, domain, and type. There’s no filter dropdown and no bulk actions.

​
Tenants and sub-tenants

Tenants form a tree. A sub-tenant is a tenant inside another, which is how you model departments, environments, or customers under one organisation. The primary button changes with your context: New Tenant at the top level, New Sub-Tenant when you’re inside a tenant. Creating a sub-tenant requires Domain Admin.
A parent cannot be deleted while it still has children — you’ll get Remove sub-tenants of "{name}" first. Delete a tree from the leaves up.

​
Creating a tenant

The dialog is Create Tenant, or Create Sub-Tenant in a tenant context — “Create a tenant and optionally cap its resources.” Two sections:
The tenant name becomes the domain name and is not a display label you can casually change later. Pick a stable, lowercase, meaningful name — engineering rather than Eng Team (new).
Resource limits are optional. Leaving them unset means the tenant draws against the parent’s quota, so a single sub-tenant can consume everything available. Setting caps is how you stop one team exhausting the whole organisation’s allowance.

​
Switching tenant context

If you belong to more than one tenant, a context switcher in the user menu selects which you’re acting as. It shows the active tenant’s name with a role tag — admin or member — or My Account when you’re in your personal context rather than a tenant.
Tenant context is the single most consequential setting in the console. It determines which resources you see and which tenant anything you create belongs to. Nothing prompts you to confirm it, and a resource created in the wrong tenant cannot be moved — it has to be recreated.Check the switcher before creating or deleting anything.

​
Choosing between a tenant, a project, and a role

This trips people up regularly, so:
Tenants are the heaviest of the three and the hardest to undo. If you’re unsure whether you need a tenant or a project, start with a project — promoting later is easier than untangling a tenant tree.

​
Worked example: separating staging from production

1

Decide whether you need a real boundary

If staging and production must have separate quotas, so a runaway staging deployment can’t starve production, you need tenants. If you just want them labelled apart, use projects instead.
2

Create the sub-tenants

From the parent, New Sub-Tenant → production. Then again → staging.
3

Cap staging deliberately

Set Resource Limits on staging to a fraction of your quota. This is the whole point of the exercise — an uncapped sub-tenant can consume everything.
4

Grant access per tenant

Add developers to staging and a smaller group to production via Users. Membership is per tenant, so this is where the separation becomes real.
5

Verify by switching context

Switch to staging and confirm you cannot see production resources. If you can, something is attached to the parent rather than the sub-tenant.

​
Empty and error states

A Teams screen under Settings shows the same information — it’s kept for compatibility with the older name for tenants. Prefer this screen.
There is also an organisation switcher elsewhere in the interface that is not yet functional — it’s populated with placeholder data, and its “Create Organization” and “Manage Organizations” actions do nothing. Manage real tenants here.

Users

Granting access per tenant.

Projects

The lighter grouping inside a tenant.

Quotas and limits

Quotas are per tenant.

Organization, tenants, and projects

How the layers relate.