Roles
See every role in your organization, and create, edit, duplicate, or delete custom roles built from a fixed set of permissions.
Click your avatar at the bottom of the sidebar to open the user menu, choose Organization Settings, then Roles, or go directly to /dashboard/settings/roles. This page lists every role your organization can assign to a member: the two built-in roles, Admin and Member, plus any custom roles your organization has created.
Only Admins see this page by default
Opening the Roles page requires the Roles: View permission (or Roles:
Edit, which includes it). Admin has it; the built-in Member role does not,
so Roles doesn't even show up in a plain Member's Settings sidebar.
Opening /dashboard/settings/roles directly still works the same way any
permission-gated page does: it shows a "you don't have permission" message
naming the permission you're missing, instead of the grid. Creating, editing,
duplicating, and deleting a custom role additionally requires Roles: Edit.
See Permissions below to grant either on a custom role.
The roles grid
Each row shows a role's name (with its description underneath), how many permissions it grants, and how many people currently hold it: active members plus anyone with a pending invitation for that role. A search box filters by name, a type filter narrows to Custom or System roles, and the Permissions and Members columns are sortable.
Admin and Member carry a System badge and can't be edited, renamed, or deleted, but they do get a ··· menu with a single Duplicate action. Custom roles get a ··· menu with Edit, Duplicate, and Delete. Every row is clickable (other than the menu) and opens the same detail page: a custom role's row opens editable if you hold Roles: Edit, or read-only if you only hold Roles: View; Admin or Member's row always opens read-only, regardless of which of those two you hold; see View a system role below.
Permissions
A role is a name, a description, and a set of permissions. Permissions are grouped by the area of the dashboard they control:
Prop
Type
Most areas have both a View and an Edit permission, and Edit implies View: a role with Edit on an area can always see it too. A few areas are one-sided:
- Billing and Audit log are View only: billing's quota is set by iAdvize directly, and the audit log has no editable surface for anyone, so neither has anything to edit.
- Conversations and Sites are Edit only: reading conversations, and opening a site and its pages, stay open to every member of the organization, so there's no View permission to grant. Only the destructive and configuration actions are gated; see Delete a conversation, Label now and Site settings.
A fixed list: you can't add new permission types
You compose roles from this list; you can't create a new kind of permission from the dashboard. If you need to control access to something not listed here, that's a product gap, not a configuration you're missing.
The create and edit forms present this list as a single, searchable permissions table rather than checkboxes grouped by area; see Choosing permissions below.
Create a custom role
On the Roles page, click Create role, top-right of the page title.
On the create page, enter a Name and, optionally, a Description.
Check the permissions this role should grant in the permissions table.
Creating a role opens its own page (/dashboard/settings/roles/new), not a dialog. Use the ← Roles link at the top to go back without saving. A role's name must be unique in your organization: you can't reuse the name of another custom role, or of Admin/Member.
Choosing permissions
Both the create and edit pages use the same permissions table: a search box above a scrollable list of rows. Each row shows a checkbox, the permission's name (e.g. "View agents"), its raw slug as a small badge next to the name (e.g. agents:view), and a one-line description underneath (e.g. "View agents and their configuration versions"). A running count ("N permissions selected") shows below the list.
Type in the search box to filter the list by slug or by name (for example, typing agents or "view agents" both narrow the list to the Agents permissions). Checking or unchecking a row updates the count immediately; the search only filters which rows are visible; it never unchecks anything that's already selected.
Edit a custom role
Open the ··· menu on the role's row, or click anywhere on the row itself, to reach its edit page (/dashboard/settings/roles/[slug]). Name and Description sit at the top of the page, above two tabs (Permissions and Members) that hold the rest; the Name/Description fields stay visible and editable no matter which tab is selected.
The Permissions tab holds the permissions table used to create a role. Change the name, description, and permissions as needed, then click Save changes. The change applies to everyone who holds the role; see the note on propagation below. Use the ← Roles link at the top of the page to go back.
The Members tab lists everyone who currently holds the role; see Members with this role below.
View a system role
Clicking Admin or Member's row opens the same detail page as a custom role, but read-only. The title reads Role details, with a description explaining that system roles can't be edited.
The Name field, Description field (above the tabs), and every permission checkbox on the Permissions tab are disabled: you can see exactly which permissions the role grants (and the running "N permissions selected" count), but there's nothing to check or uncheck, and no Cancel/Save footer at all.
The Members tab works exactly like a custom role's: it lists everyone who currently holds the role, active members and pending invitations alike, useful for checking, for example, how many people currently hold Admin.
Duplicate a custom role
Open the ··· menu on an existing custom role and choose Duplicate. This opens the create page at /dashboard/settings/roles/new?duplicateFrom=<slug>, pre-filled with that role's description and permissions, and its name suffixed "(copy)". Adjust anything you like and click Create role. This always creates a brand-new role; it never changes the one you duplicated from.
Duplicating a system role
Admin and Member also have a ··· menu with a Duplicate action, even though neither can be edited or deleted. Use it to start a new custom role from the same permissions as a system role, instead of checking every box by hand.
Members with this role
The Members tab on a role's detail page shows a read-only table of everyone who currently holds the role: every active member (avatar, name, email), plus anyone with a pending invitation for it, tagged Invitation sent. There are no actions here. To move someone to a different role, go to the Members page. The same tab, populated the same way, is also on a system role's read-only page; see View a system role above.
Delete a custom role
Open the ··· menu on the role's row and choose Delete, then confirm. This can't be undone.
If any active member or pending invitation still holds the role, the delete is blocked: you'll see how many people hold it and a reminder to reassign them from the Members page first. Admin and Member can never be deleted.
Assigning a role to a member
Every role, system or custom, is available in the role picker when you invite a teammate or change an existing member's role. A member always holds exactly one role.
Your organization always needs an Admin
You can't remove or demote the last member holding the Admin role, even if you demote them to a custom role instead of Member. Promote someone else to Admin first.
Permission changes take a moment to apply
A permission change follows a member around the dashboard by way of their signed-in session, not in real time. If you edit the permissions of a role a teammate currently holds, they keep their previous access until they next sign in (sessions also refresh naturally on their own). If you change your own role, your access updates immediately.
What's covered today
Only the areas listed under Permissions are actually gated: organization profile, members, API keys, roles, agents, connectors, engagement widgets, starter questions, billing, the audit log, conversation deletion, and site management. Editing or promoting an agent version and managing a connector's credentials are the two most sensitive actions in the dashboard, so those are enforced end to end: both the pages themselves and every save button behind them check the permission again. Other dashboard areas aren't gated by a permission yet.
Each area with a View permission follows the same pattern, billing included: its entry in the Settings sidebar (or, for Agents, Connectors, Engagement widgets, and Starter questions, the main dashboard sidebar) only shows up if you hold at least its View permission, and going to the page directly without it shows a plain restricted-access message naming what you're missing instead of an error.
Conversations and Sites work differently, since neither has a View permission: no page is hidden from a sidebar for lacking one, and reading a conversation or opening a site's pages stays open to every member. Instead the affordances themselves disappear. Without Conversations: Edit, the Delete button on a conversation's detail page isn't rendered, and neither is Label now in its Analysis section. Reading the Analysis section needs no permission. If a request to label a conversation reaches the server without the permission, it's refused and recorded as a blocked attempt in the audit log. Without Sites: Edit, Create site is missing from the site switcher, and every one of a site's Settings pages (General, Languages, Branding, and Public access) withholds its save/delete/immediate-write controls (see Site settings for exactly what each page hides). The onboarding review screen (and its degraded, description-only fallback) follows the same rule for the site fields it lets you edit (see Review what we generated), except its Assistant name row, which is gated on Agents: Edit instead, since saving it mints a new agent configuration version rather than writing the site. /dashboard/sites/new is the one page that is genuinely blocked: going there without Sites: Edit redirects you to the dashboard, silently, with none of the restricted-access message the View-gated pages show.