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

# Roles and access

> What an administrator, a developer and a member can each do in the dashboard.

# Roles and access

Your organization has three roles: **administrator**, **developer** and **member**. The role decides which sections of the dashboard a person sees and what they may change inside them.

<Note>
  In the role selector on the Organization page the three are labelled **Admin**, **Developer** and **Member**, and the controls that refer to the third one use the same word — **Visible to members** on an agent, for example.
</Note>

A section a role does not have is genuinely absent: it is not greyed out, and opening its address directly leads back to the dashboard rather than to an error.

## Sections by role

**●** available · **◐** available with a restriction · **—** not shown

### Running the business

| Section              | Administrator | Developer | Member |
| -------------------- | :-----------: | :-------: | :----: |
| Dashboard            |       ●       |     ●     |    ●   |
| Campaigns            |       ●       |     ●     |   ● ¹  |
| Call history         |       ●       |     ●     |   ◐ ²  |
| Do-not-call registry |       ●       |     ●     |   ◐ ³  |
| Calling rules        |      ◐ ⁴      |    ◐ ⁴    |   ◐ ⁴  |
| Incidents            |       ●       |     ●     |    ●   |

¹ A member runs the whole campaign lifecycle — see below.
² Without the full call log export; reports — their own only.
³ The **Registry** tab, yes; the **Capture** settings, no.
⁴ Only on the US market profile, and read-only: the rules themselves are set by the platform.

### Building agents

| Section           | Administrator | Developer | Member |
| ----------------- | :-----------: | :-------: | :----: |
| Agents and editor |       ●       |     ●     |    —   |
| Components        |       ●       |     ●     |    —   |
| Knowledge bases   |       ●       |     ●     |    —   |
| Phrase fixups     |       ●       |     ●     |    —   |
| MCP servers       |       ●       |     ●     |    —   |
| Telephony         |       ●       |     ●     |    —   |
| Demo links        |       ●       |     ●     |    —   |

### Administration

| Section                | Administrator | Developer | Member |
| ---------------------- | :-----------: | :-------: | :----: |
| API keys               |       ●       |     ●     |   — ¹  |
| Organization and users |       ●       |     —     |    —   |
| Settings               |       ●       |     ●     |   ◐ ²  |

¹ Closed to a member even for reading.
² Without the **Defaults for new agents** section.

## The member role in detail

An open section does not mean full rights. A member's list of permitted changes is closed by default and enumerated by name: anything not on it is forbidden, including new capabilities added later to sections they already see.

**Can change**

* **A campaign, end to end** — create, edit, upload contacts, launch, pause, resume, cancel, and decide on matches against the do-not-call registry
* **Dialing presets** — create, edit, delete
* **The do-not-call registry** — add, remove, import, review
* **Reports** — build and download their own
* **Their own interface settings**

**Cannot**

* **Delete a campaign** — even though launching and cancelling it are allowed
* **Export a call log** — that is personal data: transcript, numbers, variables
* **Delete a report**, including their own; other people's reports they do not see at all
* **Open API keys** — the section is closed even for reading
* **Configure do-not-call capture** — that is agent behaviour, not registry content
* **Set defaults for new agents**
* **Manage users and the organization**

<Warning>
  **The right to launch is the right to sign.** A member who launches a campaign signs the consent attestation in their own name — that person stands behind the record. Worth keeping in mind when handing the role out.
</Warning>

### Which agents a member sees

The Agents section and the builder are closed to a member, so the only place they meet agent names is the choice of an agent for a campaign — and that list is filtered. An agent marked [hidden from members](/v4/platform/agents/list) is not offered to them for a new campaign, and the platform refuses such a choice on the server rather than merely leaving it out of the list. Administrators and developers see every agent and are the only ones who can change the setting.

Hidden is not secret: a campaign already running on such an agent stays fully visible and manageable for the member who owns it, and the agent filters of History and Incidents keep listing hidden agents so that old calls remain findable.

## Organization users

The **Organization and users** section is open to administrators only. The user list has **search and pagination**: in an organization of a hundred people you find someone by typing a name rather than by scrolling.

### There is no user deletion — there is deactivation

An account is not deleted but **deactivated**: the person loses access while the record stays visible in the list and can be switched back on. It works this way because an email address is globally unique: a taken address could otherwise be neither freed nor recovered.

### Moving a user between your organizations

When someone moves from one of your companies to another, their account is **transferred** rather than created anew. The operation is available to an administrator whose subtree contains **both** organizations; an account outside the subtree answers "not found" — indistinguishable from one that does not exist, so the response cannot be used to probe addresses.

The transfer takes effect from the user's next request and is written to the audit log on both sides.

## Where developers stop

A developer can do everything an administrator can, except manage the organization itself: users, the organization tree and organization-level records stay with the administrator.