This guide walks through the practical steps for managing roles and permissions in your MX8 Labs account. Before getting started, it helps to read the Understanding Roles and Permissions overview so you are familiar with the concepts of resources, actions, and constraints.

Accessing the Permissions Tab

To manage roles, navigate to your account settings and select the Permissions tab. You will see a dropdown at the top of the page that lets you choose which role to view or edit. The page displays the selected role's name, whether it is a system role or a custom role, and the full list of resource permissions assigned to it.

System roles (account_member and account_admin) are visible here so you can review their permissions, but their permission bundles are managed by the platform and cannot be edited through this interface. Custom roles are fully editable.

Viewing a Role's Permissions

When you select a role from the dropdown, the Role Permissions by Resource table shows every resource that has been granted permissions under that role. Each row displays the resource name on the left and the list of granted actions as labels on the right. This gives you a quick overview of what the role can do.

If a resource does not appear in the table, the role has no permissions on that resource (beyond any wildcard grants). A row showing All Resources with the read action means the role has blanket read access to everything in the account.

Creating a Custom Role

To create a new role, click + Create Role in the upper right area of the Permissions tab. Give the role a descriptive name — for example, field_manager for someone who manages live audiences, or analyst for someone with read-heavy access and limited editing capability.

Once the role is created, it starts with no permissions. You build up its access by adding resources and configuring the actions and constraints for each one.

Adding a Resource to a Role

Click + Add Resource to add a new resource to the role. Select the resource you want to grant permissions on (for example, survey or audience), then configure the actions and constraints. Each resource can only appear once in a role's permission table, but you can assign multiple actions and constraints to it.

Editing Permissions on a Resource

To modify the permissions for a resource that is already assigned to the role, click the edit (pencil) icon on that resource's row. This opens the Edit Resource Permissions dialog.

In this dialog you can:

• Add an action — Use the "Add action" dropdown to select an action (such as read, create, update, or delete) and add it to the permission set for this resource.
• Remove an action — Click the red delete icon next to an existing action to revoke it.
• Set a constraint — For each action, you can optionally select a constraint type from the dropdown. The available constraint types are:
  • No constraint — The action applies without restriction.
  • allowed_values — Specify a list of values that are permitted for a particular field. The action will only be allowed when the target field matches one of the listed values.
  • denied_values — Specify a list of values that are blocked for a particular field. The action is allowed for all values except those listed. Denied values always override allowed values if both are set.
  • field_subset — Restrict an update action to a specific set of fields. The user will only be able to modify the listed fields and any attempt to change other fields will be denied.

When you are finished, click Save Changes to apply the configuration.

Example: Creating a "Field Manager" Role

Suppose you want a role that can take audiences live and manage respondent sources, but cannot create or delete surveys. Here is how you would set it up:

1. Click + Create Role and name it field_manager.
2. Click + Add Resource and select audience. Add the actions create, update, delete, and go_live.
3. Click + Add Resource again and select survey. Add only the read action. (All other survey actions will be denied by omission.)
4. If you want to restrict the audience types this role can create, edit the audience resource, select the create action, choose the allowed_values constraint, and specify the permitted audience type values.
5. Click Save to finalize the role.

Example: Restricting API Access

If you have a team that should be able to work freely in the platform UI but should not trigger operations through the API, create a custom role that includes the internal actions (read, create, update, delete) but omits the external channel actions (api_read, api_run, mcp_read, mcp_run). Because permissions are evaluated per-action, the absence of API actions means any API requests from users in this role will be denied.

Assigning Roles to Users

Roles are assigned to users through the Team tab in account settings. Each user can hold one or more roles within the same account. When a user holds multiple roles, their effective permissions are the union of all assigned roles — permissions are additive, so the user gets the combined access of every role they hold.

The account's default role determines which role is automatically assigned when a new user is added. By default this is account_member, but an administrator can change the default role to any role in the account.

Deleting a Custom Role

To remove a custom role, select it from the dropdown and click Delete Role. System roles cannot be deleted. Before deleting a role, make sure no users depend solely on that role for their access, as removing it will revoke those permissions immediately.

Tips for Designing Roles

• Start with the system roles. The built-in account_member and account_admin roles cover the majority of use cases. Only create custom roles when you need access patterns that do not map to either.
• Use constraints sparingly. Constraints are powerful but add complexity. A clean set of resource and action grants is easier to audit than a web of field-level constraints.
• Audit regularly. Review the Permissions tab periodically to make sure custom roles still reflect your team's access requirements, especially as new team members join or responsibilities shift.
• Remember that permissions are additive. If a user holds both a restrictive custom role and account_admin, the admin permissions will still apply. Design roles with this in mind.

For the full list of every resource, action, field, and constraint available in the system, see the Permissions Reference.