--- title: "Roles and per-feature permissions" description: "CloudFly Helpdesk grants access along two independent axes: the workspace role, administrator or agent, and the permission groups that decide who may write." updated: "2026-08-28" audience: [agent, administrator] source: "https://helpdesk-docs.svr1.feedapp.click/en/khai-niem/vai-tro-va-quyen" --- What an account may do is decided by **two independent axes**, not one. Treating them as a single setting produces our most common support question. It runs: "I am an administrator, so why can my colleague not send a message?" ## Axis one — the workspace role [#axis-one--the-workspace-role] Every account carries exactly one role, set in the **Role** field on the user profile: `Administrator` or `Agent`. The **Users** roster repeats that value as a badge beside the name. The role governs who may touch workspace-wide configuration: adding and removing accounts, editing **General**, editing **Templates**, opening **Background Jobs**. The edit controls on **SLA Policies** and **Working Calendars** appear for administrators only. An administrator is also a superuser on the second axis: every group limit is bypassed for them. Dropping an administrator to read-only therefore restricts nothing, and the way to restrict one is to change their **Role** first. The role says nothing about answering customers, though. An agent can be the person who handles the entire queue, as long as they hold the matching group on the second axis. ## Axis two — permission groups [#axis-two--permission-groups] Read and write access is granted to a **group**, and the group is then handed to an account. No field on the user profile says "conversations role" or "tickets role" — that access lives in the groups. Six groups ship with the workspace: | Group | Key | What it allows | | ----------------------------- | ---------------------- | ---------------------------------------------------------------------------------------------------- | | Internal User | `base.user` | Reads shared workspace data. Every operator holds it, even one whose profile carries no group at all | | Conversations / Member | `conversations.member` | Reads the queue under **Conversations** | | Conversations / Administrator | `conversations.admin` | Writes under **Conversations**: messages, threads and the conversation itself | | Tickets / Member | `tickets.member` | Reads tickets under **Tickets** | | Tickets / Administrator | `tickets.admin` | Writes on tickets and on ticket replies | | Administration / Settings | `base.administrator` | Full access; every limit is bypassed | Holding a group means holding the groups it implies: `conversations.admin` implies `conversations.member`, and that one implies `base.user`. Permissions add up across the groups an account holds, and there is no way to subtract one that another group turned on. > **Note:** Group names and keys are stored once and print in English in both consoles. > A Vietnamese colleague reading the same screen sees the same > `Conversations / Administrator` you do. ## Where a group is granted [#where-a-group-is-granted] Groups are ticked in the **Groups** block on the profile of an account that already exists, along **Administration** → **Users** → pick the person. The block is absent from the creation form, because there is no account id yet to attach a group to. A freshly created account holds no group. That person reads the shared data through `base.user` and writes nowhere until you grant them a group. What each group contains — read, write, create and unlink per table, plus any group you add beyond the six — lives under **Administration** → **Access Rights**. The steps are in [Grant per-feature permissions to a group](/en/quan-tri/phan-quyen). ## What the screen says when access is denied [#what-the-screen-says-when-access-is-denied] The interface hides a control outright rather than showing it and letting the server answer 403. Where hiding is not possible, the console prints these exact sentences: * In the conversation composer: "Your account can read conversations but not write in them. Ask an administrator for the conversations admin role." * On a ticket: "Your account can read tickets but not write on them. Ask an administrator for the tickets admin role." Either sentence means the second axis is blocking you, not that the account has been disabled. The fix is the `conversations.admin` or `tickets.admin` group, not a change of workspace role. ## The two axes combined [#the-two-axes-combined] | Role | Groups held | What this account can do | | ------------- | -------------------------------------- | ---------------------------------------------------------------- | | administrator | any group | Everything, workspace configuration included | | agent | `conversations.admin`, `tickets.admin` | Answers customers and works tickets, cannot change configuration | | agent | `base.user` alone | Reads the content, writes nothing onto it | That third row is where every new account starts, and it is the useful shape for an intern or for a manager who follows the queue without answering in it. Neither axis substitutes for the other. A group carrying access to the `users` table still does not open the **Users** screen, which asks for the workspace role directly and answers **Access Denied** to anyone who is not an administrator. ## Read next [#read-next] * [Grant per-feature permissions to a group](/en/quan-tri/phan-quyen) * [Shared inboxes and channels](/en/khai-niem/inbox-va-kenh) * [Conversations versus tickets](/en/khai-niem/hoi-thoai-vs-ticket) * [Glossary of helpdesk terms](/en/khai-niem/thuat-ngu)