Roles and per-feature permissions

CloudFly Helpdesk grants access along two independent axes: the workspace role, administrator or agent, and the permission groups that decide who may write.

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

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

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.

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

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.

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

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.