SemAgentRoles & Permissions
Admin Panel → Roles & Permissions is where you decide, on one screen, what everyone in your account can see and change. Every setting here is enforced on the server.
The permission matrix
At the centre of the screen is a table: rows are panel sections, columns are roles. Every cell takes one of three values:
| Value | What it does |
|---|---|
| none | The section is closed to this role. It does not appear in the menu either. |
| view | Can open and read — cannot change. |
| edit | Can add, change and delete. |
This table is not decoration. The server consults the same matrix on every request, so setting a cell to "none" genuinely closes those endpoints. Hiding it from the menu is only a convenience — typing the address by hand does not get anyone in.
The two non-delegable rows
Roles & Permissions and Billing stay with the account owner and cannot be opened to any other role. The reason is simple: whoever can grant permissions can grant themselves everything, and the payment method and plan belong with the owner. Both rows show a lock in the table, and the server refuses them for anyone but the owner regardless of what the database says.
Adding a custom role
If the five built-in roles (Owner · Admin · Editor · Viewer · Member) are not enough, + Add role lets you define your own:
| Field | Description |
|---|---|
| Display name | The name shown in the panel and the user list (e.g. "HR Specialist"). |
| Key | The technical name stored on the user record. Up to 20 characters; lowercase letters, digits, - and _. Cannot be changed later. |
| Base role | The new role is born with this role's permissions; you then adjust it in the matrix. The owner role cannot be a base. |
A role in use cannot be deleted. If you try, we tell you how many people hold it and refuse. Here is why: an unrecognised role falls back to the most restricted one, so deleting a role in use would change those people's permissions with nobody told. Give them another role first.
Folder scope
A second table on the same screen decides which role may use which knowledge base folder. Close a folder for a role and its content is not used in that role's chats or agent searches, and does not appear in their list.
The customer-facing widget is unaffected. A visitor has no role; folder scope is a statement about your own team. In the widget, only the account-wide folder switch on the Knowledge Base screen applies.
The owner role is exempt and cannot be restricted — whoever sets the scope must not end up unable to see their own content.
When does a change take effect?
Immediately. A user's role is read from the database on every request, not written into the ticket they got when signing in. So when you change someone's role they do not have to sign in again; their next click runs with the new permissions. This is not a setting — it follows from how the system is built.
What does the matrix cover?
Below the table you will find a note saying how many endpoints the matrix actually governs. It governs a portion of the tenant-facing endpoints; the rest are protected by their own checks — which is why a screen can look "open" in the matrix and still require admin rights. Hiding the number would leave the impression that everything is managed from this one table.