Understand tenants, user accounts, and the System view

This reference helps administrators diagnose tenant visibility, user account, profile, and System-view questions. It explains which tenant list to check and why the System count is different from a user's personal tenant selection.

Use this page when a user cannot see a workspace, when the System page shows a different tenant count than expected, or when you need to distinguish personal membership from system-wide administration.

Core concepts

Term	Meaning
User account / identity	Global account used to sign in.
Workspace	Business context in which users work.
Tenant	Technical and organizational data context of a workspace.
Membership	Assignment of a user account to a tenant with a role and permissions.
Profile binding	Link between a user account and its profile in a tenant. It makes the workspace usable in a complete browser session.
Active session	The tenant currently selected for the browser session.
System Tenant	Special context for system-wide administration, operations, and cross-tenant lists.

How the components relate

The personal tenant list answers: Which tenants is this user account a member of? The System page answers a different question: Which tenants can an authorized system administrator see in system-wide tenant administration?

The app footer shows the active tenant's name and type. When you work in the System Tenant, Workspace also highlights the System context. Check this indicator before creating business data if your account can switch between multiple tenants.

Select the tenant indicator to choose another tenant from your own memberships. Workspace applies the change only after the server has verified your membership, then reloads the app in the selected context. With one membership, the indicator remains status information and does not open a switcher.

If Workspace cannot resolve exactly one active tenant from the session, the footer does not guess a name or type. The error remains neutral status information and does not offer another load attempt. Do not create business data while the indicator is unavailable.

Workspace adds another safeguard to two create flows. When you create a CMS site or a public Tenant Domain with the cms_public surface in the System Tenant, Workspace requires explicit confirmation. Cancel ends the flow without sending a create request. Confirmation applies only to the current operation and is not stored as a permanent exception.

What each tenant list means

View	Purpose	Result
Personal tenant list	Shows tenants where the signed-in user account is a member.	The user sees their workspaces and the currently active tenant.
Browser-session tenant selection	Selects a tenant that is ready for a complete session.	The user works in the selected workspace.
System tenant list	Shows tenants in the System Tenant context with suitable system permissions.	System administrators see cross-tenant administration.
`/system` tenant count	Counts entries in the System tenant list.	The number represents the system-wide list, not the personal list.

The personal and System lists can contain the same number of tenants. Their sources still differ: the personal list comes from memberships, while the System list comes from system-wide permissions.

Verify access

Check visibility questions in this order:

Decide whether the question concerns personal tenant selection or the System page.
For personal visibility, verify that the user account is a member of the tenant.
For browser sessions, verify that the user account has a suitable profile binding in the tenant.
For the System page, verify that the account is working in the System Tenant and has the required system permissions.
Check the app footer and confirm that tenant name and type match the intended context.
Then check roles, access groups, and page audiences in the workspace.

The check is successful when the user can select the expected workspace, sees the page in the correct context, and can access the System page only with the required system permissions.

Next steps