Roles and permissions¶

Your access on the DialoX platform is determined by:

Super user — A per-user setting that grants platform-wide access.
Roles — Roles assigned to you per organisation (including the Administrator role that gives full access within a scope).
Organisation type and license — Which roles can be assigned in a given organisation (for example, the Developer role may be disabled by your license).

This page describes how this works and what each role can do.

Super user: user setting vs Administrator role¶

There are two ways to have full (“superuser”) access; they are not the same.

Super user (user setting)¶

Where to set it: In Studio, go to Manage → Users, open a user, and turn on Super user.
Effect: That user has full access across the entire platform (all organisations). The platform does not apply role-based restrictions for this user.
Needed for (only this setting counts, not the Administrator role):
License management and license templates
Provisioning (e.g. creating organisations via the provisioning API)
Billing
Global conversations (platform-wide list)
Manage → Conversations
Create agency
Editing the Super user setting for other users
Some administration-only features (e.g. certain exporters)

So: Billing, provisioning, global conversations, and “Create agency” require the Super user user setting, not just the Administrator role on an organisation.

Administrator role (per organisation)¶

Where to set it: Like any other role, in Manage → Users when you assign roles for a user on an organisation.
Effect: Within that organisation and its child organisations, the user has full access. They do not get platform-wide access (e.g. no Billing, no Create agency, no global conversations list unless they also have the Super user setting).
Typical use: Give someone full control over one environment or one agency tree without making them a platform-wide Super user.

Summary: the Super user setting = platform-wide full access. The Administrator role = full access only within the organisation tree where it is assigned.

Roles¶

Roles are assigned per user per organisation. A user can have multiple roles in one organisation.

The following roles are available. The name in the first column is what you see in Studio.

Role	Description	Environment or customer	Agency
Organisation manager	Manage environments and users	Yes	Yes
Developer	Bot development and configuration	Yes*	Yes
Content manager	Access to the CMS	Yes	Yes
Operator	Full inbox and CRM access	Yes	No
Agent	Inbox access for live chat	Yes	No
Producer	Full access to settings, CRM, CMS, analytics	Yes	Yes
Analyst	Access to analytics and CRM (read-only)	Yes	Yes
Supervisor	Inbox and CRM access, not assignable to conversations	Yes	No
Planner	Configure the calendars and planners	Yes	Yes
Administrator	Full access within the organisation scope	Yes	Yes

* The Developer role can be disabled for an organisation by license. When it is disabled, it cannot be assigned there.

Environment or customer: Any of the roles above can be assigned.
Agency (e.g. root, GTM): Only agency roles can be assigned: Content manager, Planner, Developer, Analyst, Producer, Organisation manager, and Administrator. Agent, Operator, and Supervisor are not available on agency nodes; they are used only on environments.

What each role can do¶

Below is a summary of what each role can do. Users with the Super user user setting can do everything. Users with the Administrator role on an organisation can do everything within that organisation and its children. For other roles, only the listed capabilities apply.

Organisation manager: Manage the organisation (environments and users), create bots, view and manage licenses, manage access requests, manage store listings.
Developer: Create bots, publish skills, manage package releases, build bots, change bot settings, publish, manage intents and knowledge bases, train models, edit bot code and flows, manage frontends and content scripts, broadcast, use bot filesystem and files, manage calendars and calendar events/slots, manage webhooks, write conversations.
Content manager: Publish bots, manage intents and knowledge bases, create and edit content scripts, use bot filesystem and files, edit CMS content (script content).
Operator: View and manage conversations, CRM, inbox (full inbox and operate), view and edit bot users, view and manage notes, use calendars and calendar events/slots.
Agent: Same as Operator except no full inbox view (e.g. cannot see all conversations in the same way); can use inbox and operate, view and manage conversations, CRM, bot users, notes, calendars.
Producer: Analytics, conversations, CRM (read and write), broadcast, dashboard, inbox (full), intents, knowledge bases, train, notes, calendars, configure calendars, publish, bot settings, bot users, create frontends and content scripts, public inbox view, script content and flow, webhooks, filesystem, create bots, view license.
Analyst: Analytics, conversations, CRM, dashboard (read-only), view bot users.
Supervisor: Same as Operator in terms of inbox, CRM, conversations, bot users, notes, calendars; not assignable to conversations (used for oversight).
Planner: Calendars, publish, configure calendars, calendar events/slots, access notes.

Anyone who can log in can: view organisations they have access to, view bots, view scripts, and view job status (read-only).

Some actions (e.g. creating licenses) are only available to users with the Super user user setting or the Administrator role in the relevant scope.

Special cases¶

Embedded inbox (e.g. Inbox SDK)¶

When the inbox is embedded (e.g. via the Inbox SDK), only the Agent, Operator, and Supervisor roles are taken into account for inbox access. Other roles (e.g. Producer, Developer) do not grant inbox-related permissions in that context; only those three roles (and Administrator/Super user) do.

Assuming a role¶

When a user assumes another role (e.g. support staff acting as a specific organisation role), the Super user user setting is ignored for that session. Only the assumed role’s permissions apply. A platform Super user who assumes a limited role will only have that role’s access until they stop assuming.

Multi-factor authentication (MFA)¶

MFA is required when:

The user has the Super user user setting, or
The organisation has MFA enabled and the user has Organisation manager or Administrator role in that organisation.

Store listings¶

Root or GTM: A user with the Administrator role on that organisation (or a parent) can manage store listings for that tree.
Distributor: The Administrator role at distributor level does not get the same store-listing privileges; only Administrator at root/GTM or the Super user user setting can do everything.
Super user (user setting): Can manage store listings at any level.

License limits¶

Your organisation’s license can restrict which roles are available. For example, the Developer role can be disabled per organisation. When it is disabled, it cannot be assigned in that organisation.

Role inheritance (agency and environments)¶

Users who have agency roles (including Administrator) on a parent organisation (e.g. an agency) automatically get a corresponding level of access on child organisations (e.g. environments). The inherited access does not include Agent, Operator, or Supervisor; those must be assigned directly on the environment. So for example, a user with Developer on an agency effectively has developer access on all child environments without being assigned there.

Summary¶

Super user (user setting) → Full access across the platform: billing, provisioning, global conversations, create agency, and all other features.
Administrator role (per organisation) → Full access only within that organisation and its children. Does not by itself grant billing, provisioning, global conversations, or create agency.
Other roles → Access as listed above, within the organisations where the role is assigned (or inherited from a parent agency).