Members and roles
Access in Kumkuat is scoped to a workspace. A person can belong to several workspaces with a different role in each.
Roles
| Role | Summary |
|---|---|
| Owner | Full control including workspace deletion |
| Admin | Manages members, sources, audiences, models, toggles and integrations |
| Member | Uses every enabled feature; creation rights are governed by permissions |
| Viewer | Read-only |
Permissions
The Permissions tab lets admins grant or withhold specific rights per role, for example:
- create and edit personas (the persona-write permission);
- Create and edit knowledge bases and sources;
- Create, edit and run alerts, and Send alerts outside Kumkuat by email, Slack or webhook;
- Email reports;
- Change workspace settings, such as the company profile, competitors and auto tags;
- Manage integrations and Run background jobs (owners and admins by default);
- View and export the audit log (owners and admins by default; it can be granted to viewers). See Audit log.
Viewers are read-only: apart from viewing rights, the Viewer column is locked off, and a viewer can change only their own settings, chats and keys.
Writes are checked on every request, so a permission removed in settings takes effect immediately.
Single sign-on
Members can also arrive through your organisation's identity provider: with single sign-on configured, anyone who signs in through it joins the workspace with the default role you chose, and their access ends when you remove them in the identity provider.
API keys and members
A workspace API key acts with the rights of the workspace, not of the person who created it. Keep keys in a secret store and rotate them when a member with key access leaves. See REST API.