Roles & Permissions

Cloudax Connect uses a granular, role-based access control system to manage what each member of your workspace can do. Every user is assigned a workspace role that provides a sensible set of default permissions. Admins can then fine-tune access on a per-member basis by toggling individual permissions; no need to create a new role for every edge case.

Workspace Roles

There are five workspace roles, each with a different default set of permissions. Choose the role that best matches the responsibilities of each team member, then customise individual permissions as needed.

Admin

admin: Full access to all workspace features. Admins can manage billing, view cost data and reports, invite and remove members, change roles, customise per-member permissions, and access the Partner Dashboard. This role is intended for senior administrators who need complete control over the platform.

Billing Manager

billing_manager: Member-style operational access plus the financial permissions: billing, cost data (dashboard and analytics), and reports. Billing managers can view invoices, see cost breakdowns, and access financial reports. They do not get the Inbox workspace or wallboard editing; those are reserved for hands-on operations roles. This role is ideal for finance team members who need billing visibility alongside day-to-day operational access.

Member

member: Full operational access to the platform. Members can view, create, edit, and delete agents, campaigns, files, and wallboards (including sharing wallboards externally); import phone numbers; and have access to call logs, tool logs, webhook logs, integrations, tickets, emails, personalities, cost data, the omnichannel Inbox, and the Developers page. They do not see billing or reports by default. This is the standard role for team members who build and maintain AI agents on a daily basis.

Logs Only

logs_only: View-only access to the dashboard, analytics, call logs, tool logs, and webhook logs. Users with this role can also export call log data. This role is designed for quality assurance, compliance, or monitoring staff who need to review activity without making changes.

Read Only

read_only: View-only access to the dashboard, analytics, call logs, tool logs, webhook logs, agents, phone numbers, personalities, the omnichannel Inbox, wallboards, and the Developers page. Users with this role cannot make any changes: they cannot import phone numbers, create or edit agents, reply in the Inbox, or modify any other resource. This is useful for stakeholders, auditors, or external consultants who need visibility without the ability to modify anything.

Default Permission Matrix

The following table shows the default permissions granted to each role. Admins can override these defaults on a per-member basis (see Customising Permissions below).

Dashboard & Analytics

Logs & Monitoring

Agents

Campaigns

Files

Phone Numbers

Import Phone Numbers controls who can run the import wizard to add Twilio, Vonage, TelXL, Gamma, Telnyx, Plivo, Wavix, or SIP numbers. Members without this permission can still see the Numbers page (if they have View Phone Numbers) but the Import button is hidden, and the underlying API rejects any direct import attempt. This is useful when you want a Read Only auditor or a Logs Only QA user to verify which numbers are connected without being able to add new ones.

Other Features

Create Sub-Organisations (Partners)

The Create sub-organisations permission lets a member create new client and sub-partner workspaces under an organisation, directly from the workspace selector, without needing full platform-admin access. It is granted to Admins by default and can be toggled on for any individual member using the per-member overrides described below.

A member can only create sub-organisations under organisations where they actually hold this permission, and the new workspace is attributed to that partner account for branding and billing. See Managing Clients for the programme-specific creation and billing workflows.

Wallboards

Wallboards have their own dedicated permission family so you can let some of your team build and share them while everyone else only views.

Wallboard editing (and share-link management) is granted to Admins and Members by default because they are the hands-on operations roles. Billing Managers and Read Only viewers can see existing wallboards but can't create, edit, delete, or share them; Logs Only users cannot see the wallboards page at all. If you want to remove share-link rights from a specific Member (because minting a public share link bypasses workspace membership: anyone with the URL, plus the optional PIN, can view the board), toggle the Share Wallboards permission off for them individually using the per-member overrides described below.

Omnichannel Inbox

The Inbox is the unified workspace where calls, chats, emails, and SMS conversations land for human follow-up. It uses its own permission family so you can decide who reads, replies, takes over from the AI, assigns, closes, or configures channels.

Configure Channels & Routing is admin-only by default because it controls how new conversations are routed and which inboxes exist; changes here affect every operator's workspace. You can grant it to specific Members via per-member overrides if you have a designated operations lead.

Customising Permissions

While roles provide a sensible starting point, admins can override the default permissions for any individual member. This means you can, for example, grant a Read Only user the ability to export call logs, or remove the delete permission from a specific Member without changing the role itself.

Per-member permission overrides are stored directly on the membership record. When a custom permission set exists for a member, it takes precedence over the role defaults entirely. Changing a member's role resets their permissions to the new role's defaults.

Call Log Visibility Scopes

On top of the on/off View Call Logs permission, admins can further restrict which call logs an individual member can see by scoping their visibility to specific agents and/or specific phone numbers. This is set per-member from the Members settings dialog when editing a user's permissions, and only appears once call_logs.view is enabled for that member.

Two independent scope filters are available:

• Agent scope: choose All agents (default, no restriction) or Specific agents and pick the agents whose call logs the member is allowed to see.
• Phone number scope: choose All numbers (default) or Specific numbers and pick the phone numbers whose call logs the member is allowed to see. Filtering matches both the modern phoneNumberId link on each call as well as legacy raw fromNumber / toNumber matches, so older logs are scoped correctly too.

Both scopes apply together: a member with an agent scope and a phone number scope only sees calls that match both filters. Scopes are enforced server-side on every call-log query (list views, exports, analytics drill-downs, and the agent/number details pages); there is no way for a scoped member to see out-of-scope calls through any UI or API path.

Per-Agent Access Control

Beyond role-level permissions and call-log scopes, workspace admins can lock an individual agent down to specific team members. Useful when only the sales team should touch the sales bot, only a partner's consultants should see a customer-facing assistant, or a sensitive agent shouldn't appear to contractors at all.

From the Agents page, right-click any agent and choose Manage access. The dialog lists every member of the workspace with a per-member toggle. Members you switch off lose the agent everywhere it could appear:

• The Agents list and the agent editor.
• The call logs and analytics drill-downs (rows for that agent disappear entirely).
• Dashboards, including any wallboards that group by agent.
• The Operator AI assistant: it can't reference, edit, or even mention the restricted agent for that member.
• Direct URL access: typing the agent ID into the address bar returns a not-found page, not a permissions error, so the agent's existence isn't leaked.

Per-agent access stacks on top of role-level View Agents: a member must have the global View Agents permission and be allowed on the specific agent to see it. Removing either is enough to hide the agent.

Assigning Roles

Roles are assigned when inviting new members to your workspace. During the invitation process, select the appropriate role from the dropdown to grant the right level of access from day one.

Workspace admins can change a member's role at any time from the Members settings page. Role changes take effect immediately; the member's permissions are updated the next time they load a page or perform an action.

When downgrading a role (for example, from Member to Read Only), the user will immediately lose access to any features not included in their new role. Any work in progress that requires elevated permissions should be completed or handed over before the role change.