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 the Roles tab, 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 the Roles tab doesn't even show up for a plain Member. 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 Admin activity are View only: billing's quota is set by iAdvize directly, and Admin activity 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, site pages, billing, Admin activity, conversation deletion, and site management. Editing an agent version or putting it live 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 tab in Organization settings (or, for Agents, Connectors, Engagement widgets, Starter questions, and Site pages, the main dashboard sidebar, where Site pages is Pages under Knowledge) 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 tab. Reading the Analysis tab 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 Admin activity. Without Sites: Edit, Create site is missing from the site switcher, and every one of a site's Settings tabs (Website, Brand, Installation, and Site access) shows no Save button and withholds its other write controls (deleting the site, rotating the key) (see Site settings for exactly what each tab hides), Go live on an agent that doesn't answer on the site is refused (the header button is disabled, with the reason), and Take offline… is missing from the Live menu (see Put an agent live or take it offline). Going live with another version of the agent that already answers needs only Agents: Edit. Deleting the agent that answers on the site needs Sites: Edit on top of Agents: Edit. 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 saves the agent's configuration 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.