Component

UI

Affected Version

all versions

Severity

Moderate – causes operational confusion, resource misallocation, and unnecessary support tickets

Description

The current "Add Account" form in the CloudStack UI is a major source of confusion, especially for administrators who are not deeply familiar with CloudStack's account‑user model. The term "Account" is often misinterpreted as a user profile, leading to the unintended creation of separate accounts in the same domain when the actual goal is simply to add a new user to an existing account.

This confusion has real operational consequences, particularly in multi‑tenant environments.

Real‑World Scenario

In our onboarding flow for a new tenant:

1. We create a parent domain where all contracted resources are allocated.
2. Inside that domain, we create a single account of type domain admin with one initial user (the primary administrator for that tenant).

This is a standard and correct setup.

However, when the tenant later needs to add a second user (e.g., a regular operator) to the same account, the administrator goes to the UI and clicks the visible "Add Account" button – because that is the only obvious action presented.

They naturally assume they are adding a new user to the current account.

In reality, they are creating a brand new, separate account with its own resource limits, quotas, and isolated resource pool.

Consequences of This Confusion

1. Incorrect Resource Limits

The newly created account uses default limits, which almost never match the contracted quota for the tenant. When the new user logs in, they see a different set of available resources than expected, leading to confusion and support escalations.

2. Unintended Resource Isolation

All resources (VMs, volumes, snapshots, networks) deployed by the new user belong to the new account, not the tenant's primary account. Users within the same tenant are therefore unable to share or even see each other's resources – which violates the expected multi‑user, shared‑resource model within a single account.

Proposed Solution

The UI should clearly distinguish between creating a new tenant account and adding a user to an existing account.

1. Rename / Relabel the Current Button

• Change the "Add Account" button label to something explicit, such as:
  "New Tenant Account"
• This signals that the action creates a separate billing/resource entity.

2. Add a Dedicated "Add User" Action

• Inside the account details view, add a clearly visible button labeled:
  "Add User to this Account"
• This action would open a simplified form that only asks for:
  • Username
  • Password
  • Confirm password
  • Email
  • First name
  • Last name
  • Timezone
• The new user would inherit the account's existing role and resource limits.

3. Add a Prominent Warning in the Current Form

Display a clear warning message at the top of the "Add Account" form, e.g.:

⚠️ Warning: Creating a new account creates a separate tenant with its own resource limits and isolated resources. Users in different accounts cannot share VMs or volumes. Networks can be shared between accounts when the appropriate permissions are granted. To add a new user to an existing account, please use the "Add User" option available from the account detail view.

Expected vs. Actual Behavior

Related Community Discussions

This confusion has been noted before in the community:

• Issue #4227 – touches on account/user ambiguity.
• Discussion #10380 – user confusion around account vs. user creation.

The underlying model is clear: an account owns resources and defines the role; a user is simply a credential to access that account. The UI should reflect this more intuitively.

Additional Context

This is not a bug in the backend logic – the system behaves correctly. The problem is purely a UX/UI design issue that leads to preventable misconfigurations. Improving the interface would:

• Reduce support overhead.
• Lower the learning curve for new CloudStack administrators.
• Prevent accidental multi‑account sprawl in production environments.