Roles & Permissions
- How custom roles let you control what your team can do, beyond the basic owner/member split
- How to create roles and grant them capabilities
- What every member can do by default, and how to narrow that baseline
- How to assign roles to team members
- How to restrict a custom type's records to specific roles
AutoTalk lets the company owner define their own roles — much like roles on a Discord server — and use them to control two things:
- Capabilities — what a role can do across the app: read or change records, send messages, work with files, run AI, run saved workflows, author automations, and administer areas of the account such as team, billing, or channels.
- Custom-type access — which roles can read, create, update, or delete the records of each custom type.
The owner always has full access and bypasses every restriction.
Opening the roles pages
In the sidebar, expand Company → Team. The roles tools are owner-only and split across three separate pages:
| Page | What it does |
|---|---|
| Roles | Create and edit roles, set their capabilities, color, and hierarchy |
| Members | Assign roles to each team member |
| Type access | Choose which roles can act on each custom type's records |
The Team group also holds Employees — invite links and your team list.
The two built-in roles
Every company starts with two system roles that can't be renamed or deleted:
- Owner — full, unrestricted access to everything. The user who created the company has this role.
- @members — automatically given to every team member. It's the baseline everyone shares, and it's editable: it ships with the Operator preset, and you can widen or narrow it at any time. Its name, color, and position are fixed; its capabilities are not.
Roles page — creating a role
- Open the Roles page and click New role.
- Give the role a name (for example, Support or Finance) and pick a color — the color is used for the role's chip throughout the app.
- Choose the capabilities this role grants — start from a preset and adjust, or pick them one by one (see below).
- Click Save.
Custom roles also have a position that sets their hierarchy — higher roles sit above lower ones in the list. You can drag roles to reorder them.
Capabilities
Capabilities are chosen in a single picker. A team member gains a capability if any role they hold grants it — including @members, which everyone holds. The picker has three parts: a grid of feature families, a list of account administration areas, and presets that fill both in one click.
The grid
Each family offers one or more levels. A higher level includes the ones below it, and the picker ticks the included ones for you — so pick the strongest level the role should have, not every level:
| Family | Level | What it allows |
|---|---|---|
| Data | Read | Read records |
| Write | Create, update and delete records | |
| Admin | Bulk and cascading deletes | |
| Messaging | Send | Send messages |
| Files | Read | Read files |
| Write | Upload files | |
| Admin | Delete files | |
| AI | Run | Run billed generation and transcription with AI |
| Workflows | Run | Run saved workflows — including the records, messages, files and AI they touch |
| Automation & code | Admin | Author and arm workflows, run code, call external URLs, mint tokens |
Files carries one extra toggle beside its levels — Create download links others can use. It is deliberately not included by Write: only Files → Admin carries it, so letting someone upload files never implies letting them hand out links that work outside AutoTalk.
Two consequences are worth spelling out:
- Workflows → Run carries whatever the workflow does. A run touches the records, messages, files, and AI its steps touch. What it does not cover is writing the workflow: creating, editing, or arming one is Automation & code.
- Automation & code is never implied. Nothing else on the grid turns it on — only Full access does. Grant it only to people who should be able to author automations and run code.
Account administration
Below the grid, Account administration holds ten toggles, one per area of your own company settings:
| Area | Covers |
|---|---|
| Team | Invite links and employees |
| Billing | Budget, credits, and subscriptions |
| Channels | Channels, integrations, and moderation |
| Custom types | Creating and changing custom types |
| Webhooks | Webhook configuration |
| Agents & profiles | Agents, transcription profiles, and voice profiles |
| API keys | Re-issuing an API key's secret |
| Data export | Data transfer and export |
| Onboarding | New-member onboarding flows |
| Agent debug | AI agent debug tools |
Everything in account administration turns on all ten at once. As the picker's own hint puts it: each covers one area of your own account settings, so grant only the areas the role needs.
Presets
Three shortcuts fill the picker for you — you can adjust anything afterwards:
| Preset | What it selects |
|---|---|
| Read-only | Data → Read, Files → Read |
| Operator | Data → Write, Messaging → Send, Files → Write, Workflows → Run, AI → Run |
| Full access | Full access to everything |
The owner role shows Full access instead of individual toggles — it already includes every capability. Deleting the company is always owner-only and can never be delegated to a role.
What members can do by default
@members ships with the Operator preset, so out of the box every team member can read and change records, send messages, upload files, run AI, and run saved workflows.
The baseline deliberately stops short of Automation & code: by default a member can run a workflow the company already saved, but can't author, edit, or arm one, and can't run code. Grant Automation & code through a role to the people who should have it. The ten account administration areas are off in the baseline too.
To make members read-only, open @members and apply the Read-only preset — or simply untick what they shouldn't have. Narrowing the baseline applies to everyone at once, and anything you take away can be handed back to specific people through a custom role, because the capabilities of all of a member's roles add up.
Members page — assigning roles
Open the Members page to see everyone in your company. Each member shows the roles they currently hold.
- Find the member you want to change.
- Click Edit roles and toggle the roles to assign or remove them.
- Changes take effect immediately — there's no need for the member to log out and back in.
Every member always keeps the @members role, and the owner always has full access regardless of role assignments.
Type access page — restricting custom-type records
By default, a custom type's records are visible to everyone in the company. The Type access page lets you lock a type's records down to specific roles, per action.
For each custom type you can choose which roles may:
- Read — view the records
- Create — add new records
- Update — edit existing records
- Delete — remove records
To grant a role access, click + Role under the relevant action and pick the role. A member is allowed an action if any of their roles is listed for that action.
Leave an action with no roles to make it owner-only — only the owner will be able to perform it. The owner always has full access to every type, so it never needs to be added explicitly.
Example: a read-only "Support" role
- In Roles, create a Support role. Its capabilities can stay empty — this example gates records through type access, and members already read through the @members baseline.
- In Members, assign Support to the relevant team members.
- In Type access, find your custom type and add Support to Read only — leave Create, Update, and Delete empty (owner-only). If @members is listed for those actions, remove it there as well, or everyone will still have them.
Support members can now view that type's records but can't change them.
How access is decided
When a team member tries to do something, AutoTalk checks:
- Is the member the owner? If so, allow it — owners bypass everything.
- Does any of their roles grant the matching capability? A member's capabilities are the sum of every role they hold, @members included, with each level covering the ones below it. Automation & code is the exception nothing else implies — only granting it (or Full access) turns it on.
- For a custom type's records, is one of their roles listed for that action? This check runs on top of the capability one: the member needs both the matching Data level and a role listed for that action on the type, otherwise it's denied.
Roles are resolved on every request, so adding or removing a role — or editing @members — takes effect right away.
Deleting a role
Open a custom role and click Delete role. If the role is still assigned to members or used in a type's access list, AutoTalk warns you first. Deleting a role removes it from every member and from every custom type's access — those members lose whatever that role granted. The Owner and @members system roles can't be deleted.
Next steps
- Inviting team members — bring new people into your company
- Company roles — switching between employee profiles
- Custom types — the records you can gate by role