> ## Documentation Index
> Fetch the complete documentation index at: https://docs.linkiasoft.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles, permissions and channel access

> Creating roles, the three things a role controls, and why data scope decides who receives chats.

**Roles** in the sidebar. Roles are either **System** (built in) or **Custom** (yours).

## A role controls three separate things

Getting one right and forgetting the others is the usual cause of "this user can't do
anything" tickets.

<Steps>
  <Step title="Permissions — what they can do">
    Which features and actions they can reach. **the role → Edit Permissions.**
  </Step>

  <Step title="Data scope — how much they can see">
    Whether they see everything or only their own records.
  </Step>

  <Step title="Auto-distribution — whether new chats are dealt to them">
    **Gets new chats** puts the role in the rotation for new inbound chats and leads;
    **No auto-assign** keeps the same own-inbox work but only receives what is assigned by
    hand. Only available when visibility is "own records only".
  </Step>

  <Step title="Channel access — which conversations reach them">
    Which channels the role covers, split by 1:1 chats and group rooms.
    **the role → Channel Access.**
  </Step>
</Steps>

## Auto-distribution decides who gets chats

A role receives automatically distributed conversations only when its **Auto-distribution**
field is set to *Gets new chats*. That field can only be turned on for roles whose data
scope is **own records only** — broader-scope roles oversee, they do not queue.

Turning it off gives you roles like **Account Manager**: the same own-inbox work as a sales
agent, but they only receive chats a manager hands them.

<Warning>
  Promoting someone to a broader-scope role quietly removes them from the chat rotation. They
  can still be assigned conversations by hand, but they stop being dealt new ones. This is
  intentional — oversight roles supervise rather than queue — but it surprises people.
</Warning>

## Channel access, and teams

A role with no channel grants receives no conversations, no matter how many permissions it
holds.

This is also how you build teams without a teams feature:

| Role         | Channels granted   | Result                      |
| ------------ | ------------------ | --------------------------- |
| Sales Team A | WhatsApp – Main    | Its own rotation on Main    |
| Sales Team B | WhatsApp – Support | Its own rotation on Support |

Distribution runs independently inside each. Membership is decided by permissions and
grants, never by the role's *name*, so a duplicated role behaves exactly like the original.

Each grant can cover chats, groups, or both — a role granted only 1:1 chats never receives
a group room.

## What you can do with a role

| Action              | Where                                               |
| ------------------- | --------------------------------------------------- |
| Create              | **Create Role**                                     |
| Duplicate           | Duplicate Role — the fast way to make a second team |
| Edit permissions    | Edit Permissions                                    |
| Set channel access  | Channel Access                                      |
| Assign to a user    | Assign to User                                      |
| View what it grants | View Permissions                                    |
| Delete              | Delete Role                                         |

<Note>
  **Duplicate, then change the channels** is almost always the right way to add a team. It
  guarantees the new role has a working permission set, and leaves only one thing to get
  right.
</Note>

## Changes made through the help assistant

The [help assistant can make some of these changes for you](/help/ai/assistant-actions) —
creating a role, setting its channel access, assigning it to someone. It can only ever do
what *you* have permission for, it always asks before applying anything, and every applied
change is written to the audit log **attributed to you**, with the mechanism recorded.

So the log reads "changed via the assistant" rather than hiding how it happened, and a
change you approved is your change. Refused and failed attempts are logged too.

## Troubleshooting

<AccordionGroup>
  <Accordion title="They log in and see almost nothing">
    Permissions. The role grants no access to the features they need.
  </Accordion>

  <Accordion title="They see the inbox but never receive a chat">
    Either no channel grants, or the role's **Auto-distribution** is *No auto-assign* (or
    its data scope is not "own records only"), so they are outside distribution. See
    [How assignment works](/help/routing/how-assignment-works#who-is-eligible-in-the-first-place).
  </Accordion>

  <Accordion title="They get 1:1 chats but never groups">
    The channel grant covers chats but not groups.
  </Accordion>

  <Accordion title="Assigning a chat to them is rejected">
    The error says which gate closed. "No role granting inbox access" is permissions; "no
    access to this conversation channel" is channel grants.
  </Accordion>

  <Accordion title="They can't open a report">
    Analytics is permission-gated, and per-agent KPI detail is admin-only.
  </Accordion>
</AccordionGroup>