Users & User Groups

Last updated: August 20, 2026

Users are the people who log into your organisation, and what each can do is governed by the groups they belong to. Cloudby's access control is permission-based rather than role-fixed: groups carry granular permissions, and users inherit them by membership, so access is composed rather than assigned in one lump.

What you will learn
  • How the access model is structured
  • What a user record holds
  • How permissions are inherited
  • What a group level means
Usera personbelongs toUser groupa rolecarriesPermissionsgranular rightsA user inherits every permission from every group they belong to
Access is permission-based: groups carry rights, users inherit them by membership simplified mockup

The access model

Three layers fit together. A user belongs to one or more user groups; each group carries a set of named permissions (granular rights like reading or editing a particular thing); and a user inherits every permission from every group they are in. Because permissions are granular and groups simply aggregate them, you build exactly the access a role needs rather than choosing from a few fixed roles.

Anatomy of a user

A user has tabs for their Profile, their Account (username, email, language, timezone), their Usergroup membership, and the resulting Permission set. A user group additionally carries a level: a plain numeric authority value, 1 and up, higher meaning more authority. Out of the box a new organisation seeds four groups to build from: Read-only and General User both at level 1, General Manager at level 2, Administrator at level 10 — you can push a group as high as level 20 for your own internal ranking, there is no fixed named ladder above that.

Level is a real ceiling, not just a label. You can never create or raise a group above your own current level, and you can never assign a user into a group above your own level either — both enforced server-side, not just hidden in the interface. Use it sparingly: the level you hold is the level you can hand out, so keep your own highest membership no broader than it needs to be.

Worked example

You create a “Sales clerk” group holding just the sales permissions, and add your counter staff to it. They can now do exactly the sales work and nothing more. A supervisor who needs both sales and reporting simply joins both groups and inherits the union of their permissions.

Edge cases and good practice

  • Compose access from groups; add a user to several rather than building one giant group.
  • A user gets the union of all their groups' permissions, so least-privilege means lean group membership.
  • Remove a departing user from the organisation rather than deleting their account. This detaches them from every user group and from the organisation itself, while their name and everything they did stays correctly attributed wherever it is referenced. There is currently no way for an organisation to deactivate-then-reactivate a user later on its own; removing them is the real, available action for taking away access.

Related