[UI] "Add Account" form misleads users into creating unintended multi‑account tenants instead of adding users

[luganofer]

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

Expected	Actual
A clear, separate workflow for creating a new tenant vs. adding a user to an existing tenant.	Only one unified "Add Account" interface exists, which heavily suggests account creation even when the intent is user addition.
Users within the same account share resources by default.	Unintended multiple accounts cause resource fragmentation and isolation.

---

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.

[DaanHoogland]

You make some fair points @luganofer and thank you for your analysis. As for your proposed solution, I fully agree with your points 1 and 3. I only have doubts with point 2. There is already a view user function within the account itself. Within that view there is an Add User button. I do not think an extra button will reduce confusion. Maybe we can make it an action button in the list - and details views for accounts?

any thoughts on that ? cc @NuxRo @ingox

[ingox]

I really love the idea. Even the account creation dialog is confusing. What information belongs to the account and what to the actual user. To separate this from the beginning would make this more clear. I'm happy with all the three proposals. Maybe some polish on the wording of the buttons is needed.

[DaanHoogland]

@luganofer , please have a look at/play around with #13981

[luganofer]

Thanks for the feedback and the positive discussion.

I agree that the button placement and wording can be polished, but I believe the core issue is that account creation and user creation are tightly coupled at the API level.

Just like when creating a domain you have the option to create it with or without an account (for organizational purposes), the same principle should apply to accounts and users:

Account creation should be independent of user creation.

The API should allow creating an account without any user initially. Users can then be added later to the account in a more deliberate and conscious way.

This would:

• Make it clear that an account is a resource container/tenant, not a user profile.
• Allow administrators to add users to an existing account with full awareness of what they are doing.
• Align the UI and API with the underlying CloudStack model.

Decoupling these two concepts would eliminate the confusion at its root. The UI can then naturally reflect this separation with clear workflows: "Create Account" and "Add User to Account".

Thanks!

[DaanHoogland]

@luganofer , two things I have trouble understanding,

1. why close this issue, it could be considdered a discussion item, but it is certainly not solved
2. what is the use of an account without user. I think (but this is a very old design decision I do not remember witnessing making) it was on purpose. If we decide that it does make sense to have an account without user, we should attack the issue.

[luganofer]

@DaanHoogland Thanks – accidental click while replying. Reopened now.

About accounts without users – let me clarify. You're right that an empty account isn't practically useful, but the same could be said about a domain without an account, and CloudStack allows that purely for organizational hierarchy.

So why not apply the same logic to accounts and users? The goal isn't to have empty accounts everywhere, but to decouple the concepts so users are added consciously and deliberately, avoiding confusion.

That said, I'm not sure if this separation could affect other areas like SAML, LDAP, or external authentication integrations. That would need to be evaluated.

The API can remain backward compatible – just make user fields optional – while the UI presents two clear workflows: "Create Account" and "Add User to Account".