> ## Documentation Index
> Fetch the complete documentation index at: https://docs.get2dial.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Roles and permissions
> How access works in Get2Dial: the three built-in roles, per-user capability overrides, and custom roles you define.
Every user in your workspace has a role that sets a starting point for what they can see and
change, and that starting point can be adjusted per user or replaced entirely with a role
you define yourself.
## How it works
Get2Dial has three built-in roles:
| Role | Typically | Ordering |
| -------------- | -------------------------------------------------------------------- | ----------------------- |
| **Agent** | Takes and places calls, works dispositions | Least access |
| **Supervisor** | Runs the floor: live monitoring, agent management, QA | Between agent and admin |
| **Admin** | Owns the workspace: users, telephony, campaigns, compliance settings | Most access |
Underneath the three roles is a finer-grained **capability system**: around two dozen
resource areas (carriers, queues, campaigns, DNC, recordings, live monitoring, API keys, and
more), each set to **none**, **read**, or **write** for a given user. A role is only a
starting set of these capabilities — assigning "Supervisor" to a user sets their
capabilities to the supervisor defaults, and you can then adjust any individual capability
for that person without changing their role label.
You can also define a **custom role**: a named, reusable set of capabilities you build once
and assign to any number of users. Assigning a custom role replaces a user's individual
capability overrides rather than merging with them — the custom role becomes the sole
source of that user's access.
## When to use it
Use the built-in roles as-is for most of your team — they match how a contact center is
actually staffed. Reach for a **per-user override** when one person needs an exception (a
senior agent who needs to see reports, for example). Reach for a **custom role** when the
exception applies to a group of people you'll be creating repeatedly — it's one definition
instead of repeating the same overrides on every account.
## What it affects
Capabilities gate both what a user can see in the workspace and what their API key (if they
have one) can do — the same capability model applies to both. Narrowing access is the main
lever for satisfying an internal security review or audit.
## Change a user's role or capabilities
In the left navigation, select **Users**, then select the person.
Choose a different built-in or custom role, or open **Capabilities** and set an
individual resource to **None**, **Read**, or **Write**.
Select **Save**. The change applies the next time they load a screen that depends on it
— no sign-out required.
To build a custom role rather than adjust one person at a time, go to **Roles** in the left
navigation.
## Limits and constraints
There is no limit on how many custom roles a workspace can define. See
[Limits and quotas](/reference/limits-and-quotas).
## Next steps