MX8 Labs uses a role-based access control (RBAC) system to manage what each user can do inside an account. Permissions are always scoped to a specific account, so the same person can have different levels of access in different accounts. This guide explains the core concepts behind the permissions model.

How Access Is Determined

When a user performs an action on the platform, four layers are evaluated in order:

1. Authentication identifies who the user is.
2. Account membership determines which accounts the user belongs to.
3. Role assignments define what the user is allowed to do within each account.
4. Subscription entitlements determine whether the account itself has the commercial capability to use a particular feature.

Roles and subscriptions are independent. A user might have the role-level permission to perform an action, but the account's subscription plan might not include that feature. Both must be satisfied for the action to succeed.

Roles

Every account has two built-in system roles that are created automatically:

• account_member — The default role assigned to every new user added to an account. Members can read all resources and perform day-to-day research tasks such as creating surveys, managing audiences, building reports, and working with coding labels and insights. Members cannot modify account-level settings, manage assets, or take surveys live.
• account_admin — Assigned automatically to the person who creates the account. Administrators have all the permissions of a member plus the ability to update the account itself, manage account assets and exposure sources, delete projects, move surveys and projects between locations, and take audiences live.

System roles are always present and their permission bundles are controlled by the platform. You can assign them to users but you cannot edit their permissions directly.

In addition to system roles, account administrators can create custom roles to model access patterns that do not fit the two built-in roles. Custom roles let you grant or restrict specific actions on specific resources, optionally with constraints that narrow those permissions to particular fields or values. See Managing Roles and Permissions for a walkthrough of creating and editing custom roles.

Resources

A resource is any type of object in the platform that permissions can be applied to. The full list of resources is:

• Account — The account record itself (name, data residency, retention settings).
• Account Asset — Shared assets such as uploaded images, logos, or files attached to the account.
• Exposure Source — Ad exposure tracking integrations used for linking advertising data to survey respondents.
• Project — A container that groups related surveys for cross-survey reporting and shared coding.
• Survey — An individual survey instrument within a project.
• Audience — A respondent audience segment deployed against a survey.
• Report — A reporting view built from one or more surveys within a project.
• Report Question — An individual question configuration inside a report.
• Report Topic — A thematic grouping of questions within a report.
• Coding Dictionary — The shared open-end coding scheme used across surveys in a project.
• Coding Label — An individual code within a coding dictionary.
• Translation — A language translation applied to a survey.
• Insight — An AI-generated or user-created insight derived from survey data.
• Todo — A task or action item tracked within the platform.

There is also a special wildcard resource (*) that represents all resources at once. This is how the system grants blanket read access to members and administrators.

Actions

Actions describe what a user can do with a resource. They fall into two groups.

Internal application actions are used when working directly in the platform:

• read — View a resource and its details.
• create — Create a new instance of a resource.
• update — Modify an existing resource.
• delete — Permanently remove a resource.
• go_live — Activate a resource (for example, launching an audience to begin collecting responses).
• move — Relocate a resource (for example, moving a survey to a different project).
• export — Export data from a resource.
• update_cache — Refresh cached data for a resource.
• run_internal — Execute an internal process associated with a resource.

External channel actions control access through the REST API and MCP integrations:

• api_read — Read a resource through the REST API.
• api_run — Execute or run operations on a resource through the REST API.
• mcp_read — Read a resource through the MCP integration.
• mcp_run — Execute or run operations on a resource through the MCP integration.

External channel actions are separate from their internal equivalents, so you can grant a user full access in the platform UI while restricting what they can do through the API or MCP.

Constraints

When assigning a permission to a custom role, you can optionally attach a constraint that narrows the scope of that permission to specific fields or values. Constraints are available in three types:

• allowed_values — Restricts a field to a specific set of values. For example, you could allow a role to create audiences only of certain types.
• denied_values — Explicitly blocks specific values for a field while allowing everything else. Denied values always override allowed values when both are present.
• field_subset — Restricts an update permission so that the role can only modify certain fields on the resource, rather than the full record.

Constraints are paired with a field that identifies which attribute of the resource the constraint applies to. The available fields include status, price, account_id, report_type, allow_synthetic, survey_id, project_id, type, name, and is_live. For a complete breakdown of every resource, action, and constraint combination, see the Permissions Reference.

How Permissions Combine

A user can hold multiple roles within the same account. When that happens, the effective permissions are resolved as follows:

• Permissions are additive — If any assigned role grants a permission, the user has it.
• Field grants are additive — If one role grants access to update the status field and another grants access to update the name field, the user can update both.
• Denied values override allowed values — If one role allows a value and another denies it, the denial wins.
• Immutable fields and hard business rules always win — Certain fields are protected at the platform level and cannot be overridden by any role configuration.

This additive model means you can layer roles to build up the exact permission set a user needs without having to duplicate permissions across roles.

Subscriptions vs. Permissions

It is worth noting the distinction between subscriptions and permissions. The account's subscription plan (visible on the Account tab) determines feature-level availability and usage limits — things like the maximum number of users, projects, or surveys per project. Roles and permissions, on the other hand, determine which actions a specific user may perform within the bounds of those subscription features. Both systems must agree for an action to be allowed.