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.
Built-in roles
These are the defaults; every column except the Owner's can be changed in the matrix.
| Role | By default |
|---|---|
| Owner | Has access to everything. Roles & Permissions and Billing stay with the owner. |
| Admin | Manages everything except Roles & Permissions and Billing. |
| Editor | Works on the knowledge base, sources, crawling and Conversations (can take over conversations); can view widget settings and reports. |
| Support agent | Sees every Publishing screen; takes over and answers conversations in Conversations. Widget settings, rules and canned responses are read-only, though canned responses can be used in chats. Formerly Viewer; the role key (viewer) is unchanged. |
| Member | A standard user: chats with the assistant and opens support tickets; screens that need admin rights stay closed. |
Who manages the inbox? Every role whose Conversations row is "edit" — custom roles included. People in those roles take over conversations and can be team members and assignees. If you saved the matrix earlier and never touched the Support agent column, the new defaults apply automatically; a column you changed stays as it is.
Adding a custom role
If the five built-in roles (Owner · Admin · Editor · Support agent · 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, 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.
Users: add, invite, edit
On the Users screen you add someone with a password or invite them by email; the edit button on their row changes their name, phone and role. The phone is entered with a country code (Turkish numbers must be mobiles) and WhatsApp / SMS handoff notifications go to it — see Human handoff. A number entered in an invitation moves to the user once they accept; deleting a user deletes their number. When a name or phone changes, the Audit Log gets a User details updated row naming the field that changed — never the number itself. People with two-step verification on show a 2FA label on their row; if someone loses their phone and their recovery codes, reset their verification with the key button on the row (only an account owner can reset an account owner's) — see Account security.
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?
The What is not covered note below the table says what the matrix leaves out. 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.