> For the complete documentation index, see [llms.txt](https://umber.gitbook.io/umber/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://umber.gitbook.io/umber/concepts/roles-and-permissions.md). # Roles and Permissions Every member of a workspace holds exactly one **role**. The role decides what they can see and do — there are no per-user overrides and no custom roles, so a person's capabilities are always answerable from their role alone. Roles are set when you invite someone and can be changed later by an owner or an admin. ## The five roles | Role | Intended for | In short | | ------------- | -------------------------- | ------------------------------------------------------------------- | | **Owner** | Whoever runs the account | Full control, including billing and organisation settings | | **Admin** | Team leads, operations | Everything an owner can do day to day, except organisation settings | | **Developer** | Engineers consuming assets | Deploy and manage collections; read-only on asset definitions | | **Creator** | Designers, content authors | Create and update assets and versions; cannot deploy collections | | **Viewer** | Stakeholders, reviewers | Read-only across the workspace | An owner is created automatically when a workspace is first signed up. Every other member arrives by invitation. ## What each role can do **C** create · **R** read · **U** update · **D** delete. A blank cell means no access at all. | Area | Owner | Admin | Developer | Creator | Viewer | | ----------------------------------------------------- | ------- | ------- | --------- | ------- | ------ | | [Environments](/umber/concepts/environments.md) | C R U D | C R U D | R | R | R | | API keys | C R D | C R D | — | — | — | | [Virtual assets](/umber/concepts/virtual-assets.md) | C R U D | C R U D | R | C R U | R | | Asset versions | C R U D | C R U D | R | C R U | R | | Deploy a version to an environment | C R U | C R U | C R U | C R U | R | | [Collections](/umber/concepts/virtual-collections.md) | C R U D | C R U D | R | C R U | R | | Collection items | C R U D | C R U D | C R U D | C R U | R | | Deploy a collection | C R U | C R U | C R U | R | R | | **Users** | C R U D | C R U D | R | R | — | | Usage figures | R | R | R | R | — | | Billing and plan | C R U D | C R U D | — | — | — | | Organisation profile | C R U | R | — | — | — | | Support tickets | C R U D | C R U D | R | R | R | {% hint style="info" %} **Viewers cannot see the Users area at all.** The Users item doesn't appear in their navigation, and the page refuses to load if they navigate to it directly. Developers and creators can see the members list but cannot change anything on it. {% endhint %} ## Rules that apply to every role A few guards hold regardless of who you are. They exist so a workspace can't be left unusable. * **You can't change your own role.** Not even an owner. Someone else with permission has to do it. * **You can't deactivate or delete yourself** from the Users area. * **The last owner can't be demoted or deactivated.** A workspace must always have at least one active owner or admin who can administer it. * **An admin can't act on an owner.** Admins cannot change an owner's role, deactivate them, or delete them. * **An admin can't create an owner.** When an admin invites someone, Owner isn't offered in the role list. Owners can invite at any level, including another owner. ## Changing a role Owners and admins change a role from a member's detail page — not from the **Edit Details** form, which never contains a role field. {% hint style="warning" %} **A role change signs that person out everywhere, immediately.** Their next request is rejected and they have to sign in again, which is what makes a demotion take effect at once rather than whenever their session happened to expire. Re-selecting the role someone already has changes nothing and signs nobody out. {% endhint %} Only roles you're allowed to grant appear in the list — an admin never sees Owner as an option. ## Related * [Workspaces and Members](/umber/concepts/workspaces-and-members.md) — what a workspace is, and the one-account-one-workspace rule * [Inviting Team Members](/umber/guides/inviting-team-members.md) — sending, resending and revoking invitations * [Managing Team Members](/umber/guides/managing-team-members.md) — editing, deactivating, removing, passwords --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://umber.gitbook.io/umber/concepts/roles-and-permissions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.