Skip to main content
Who can see and do what, inside your workspace and from outside it.

​
Roles

Roles are set per person under Settings, then Team. A few deliberate asymmetries:
  • Viewers cannot be assigned conversations. Assigning work to an account that cannot reply creates a ticket nobody can finish.
  • An agent can categorize a conversation but cannot reshape the taxonomy. Applying a category is daily work; changing the list everyone else works from is a settings change.
  • SLA policies are owner and admin only, a tighter gate than personal conveniences like macros, because an SLA target is a commitment the whole workspace is measured against.
  • Approval policies and budgets are owner and admin only.

​
Permissions follow the person, everywhere

A team member acting through Telegram, WhatsApp or an MCP client has exactly the permissions their role gives them in the console. Their role is read from your workspace at the moment of the action. It is not supplied by the caller and not inferred from the chat platform. In a shared team group, being in the room is not permission: the person who pressed the button is the person who is checked.

​
API keys

Keys are workspace-scoped and carry explicit scopes. See Authentication for the full list and the issuance flow. Key hygiene worth setting up:
  • Scope narrowly. A reporting integration needs read, not write.
  • One key per integration, so revoking one does not take down the others.
  • Set an expiry rather than relying on remembering to revoke.
  • Rotate atomically. Rotation issues the replacement and ends the old key in one step, inheriting its scopes, with an optional grace period so you can cut over without an outage.
Every key records when it was last used, from what address, and by what client, so an unfamiliar key is answerable.

​
Assistant write access

Anything that acts on your workspace from outside the console is gated twice: by the scope on the key, and by your approval policy for that action. An action set to require approval parks and posts a card showing what will happen before anyone approves it. See Assistant governance.

​
Vorel operator access

Our operator team can access your workspace to support you.
  • Every access is recorded, both reads and changes. Opening a page that shows your credentials is an audit event, not just changing them.
  • Support sessions where an operator views your workspace as you are explicitly marked, with a start and an end recorded.
  • Operator-side views that cross workspaces run as a separate database role and are audited. Cross-workspace queries without an explicit workspace filter are blocked before they can ship.
You can request an export of the audit trail for your workspace at any time.

​
Customer data access

The agent reads only your workspace’s data. There is no path by which a conversation in one workspace can surface data from another, and this is enforced at the database level rather than by application filtering. See Security overview.