Roles and permissions

On the Roles & permissions tab you decide which Chat permissions each role of your workspace holds. Chat does not create or assign roles; it only maps Chat permissions onto the roles you already have.

Who can do this

Chat permission: administration.read

Anyone with administration.read can view the tab. Changing a role needs administration.manage. Without it, the tab says: you can view these settings but need the “Manage Chat administration” permission to change them. The <code dir="auto">tenant_owner</code> has both. See the overview.

Where it is in the UI

Administration, then the Roles & permissions tab. A Where list at the top picks the context you are editing.

Option in Where	What it covers
Tenant-wide (administration)	Permissions that apply to the whole workspace. Grant `administration.read` and `administration.manage` here.
Chat inside an application	What each role may do in Chat inside that application. Only applications with Chat enabled are listed.

Each context is its own mapping. Nothing is inherited: a role that has permissions tenant-wide has none inside an application until you grant them there.

Below the list, roles are grouped as Tenant roles (roles a person holds in the workspace, such as member or a custom role) and Application roles (roles of the selected application, such as coach). Each role shows a grid of checkboxes, one per Chat permission, labelled with its description.

Rules to know

Every role starts with no Chat permissions, in every context. That includes tenant_admin.
tenant_owner is marked always everything. Its checkboxes are locked and it always holds every permission. The server refuses to change it with role_locked.
The roles and the list of Chat permissions come from the Identity Server each time you open the tab. A custom role you add there shows up here.
If Chat uses a permission that the Identity Server does not define yet, the tab says so (“Not defined in the Identity Server yet, so only the tenant owner can use them”) and lists the permissions.
A permission that is not in the Identity Server’s list is rejected when you save, with invalid_request.

Give a role permissions

Open Administration and select Roles & permissions.
In Where, choose Tenant-wide (administration) or Chat inside the application you are setting up.
Find the role. Tick the permissions it should hold, and clear the ones it should not.
Select Save on that role. The button is enabled once you change something.

Saving replaces the role’s Chat permissions in that context with exactly what is ticked. Chat confirms with “Saved permissions for the role in the application. They apply to members within about a minute.”

The first thing the owner does in a new workspace is grant administration.read and administration.manage to tenant_admin in Tenant-wide (administration), if admins should help administer Chat.

What to grant

A permission answers one question: may this person perform this kind of Chat action? It does not say whom they may talk to. Permission is not relationship.

Your backend decides who talks to whom (integrated use): grant conversations.read, messages.read, messages.send and messages.update and leave out conversations.create, groups.create and users.lookup. See Grant permissions to roles.
People start their own conversations (standalone use): see Permission sets for standalone use.

What gets audited

Every save records ROLE_PERMISSIONS_UPDATED in the audit log, with the role, the application (if any), and the permissions before and after.

Create a custom role or assign roles to people: see the Identity Server documentation.

For developers

The same action is available through the API: List role permissions, Replace a role’s permissions. These operations need a user token; a machine client never gets administration permissions.