Roles

A role is a named bundle of permissions and object access, attached to one node in the organization tree. Members assigned that role at that node receive its permissions — and its access to reports and ad accounts.

The Roles & Permissions tab

Selecting a node opens its detail panel; the Roles & Permissions tab is the second tab.

The layout has two columns:

• Left — the list of roles defined at this node, plus a Create role action at the bottom (visible if you have the Manage Roles permission).
• Right — the selected role's detail, with sub-tabs: Members (who has the role), Permissions (which permissions it grants), Reports access (which reports it opens), and Ad accounts access (which ad accounts it can see or control).

Visibility:

• With the Manage Roles permission: you see every role at this node and can edit them.
• Without it: you see only the roles you hold. Read-only.

Managing roles is available on the Business plan and above — see Plans.

Creating a role

Click Create role. The modal asks:

• Name (required) — what people will call this role in conversation.
• Propagate to child teams (toggle) — see Propagation below.

Roles are created with no permissions and no access. Open the new role's Permissions tab and toggle on what it should grant, then hand out object access on the Reports access and Ad accounts access tabs.

Editing role permissions

The Permissions sub-tab groups the catalogue in two sections — Administration and Data & Reports. Each row is one permission with its display name, a short description, and a toggle.

Toggling changes are batched:

• The bottom of the panel surfaces Save and Discard buttons once you've made unsaved changes.
• Save commits.
• Discard reverts.

You can flip multiple toggles before saving. There's no per-toggle save.

Reports access and Ad accounts access

Permissions cover what a role can create and configure. Access to reports and ad accounts that already exist lives on two more sub-tabs:

• Reports access — tick which of the organization's reports members holding this role can open. Batch across many reports, then save. Editing this tab requires the Manage Report Access permission.
• Ad accounts access — set a level per ad account: No access, Can view, or Can control (view plus start/stop sync). Batch across many ad accounts, then save. Editing this tab requires the Manage Ad Account Access permission.

This is how a read-only stakeholder works in practice: a role with no permissions at all, plus a handful of reports ticked on Reports access.

Propagation

The propagating flag on a role decides whether its permissions reach down into sub-teams.

• Propagating role at Team X → the role's permissions apply at Team X and every Sub-team under it.
• Non-propagating role at Team X → the role's permissions apply only at Team X.

Pick propagation when:

• The role is an "above-the-line" role (admin, lead) that should govern the whole branch.
• You'd otherwise have to copy the role into every sub-team.

Pick non-propagation when:

• The role is scoped to one team (e.g. Search Manager) and shouldn't apply to sibling sub-teams.
• You want to use one team's role to grant access to that team only.

You can change the propagating flag later from the role detail header.

The Owner role

Every Organization has an Owner role:

• Read-only — you can't change its permissions or its propagation toggle.
• Always propagates — Owners have every permission at every node, regardless of the toggle.
• Protected — Level refuses to modify Owner's permissions, delete the Owner role, assign Owner via the normal Manage access flow, or remove someone from Owner.

Practically: Owner is the "break-glass" role, held by the organization's owner — the person whose subscription the organization runs on. Everyone else gets narrower roles.

Editing and deleting roles

The role detail header has Edit (rename, toggle propagation) and Delete actions, both available if you can manage roles.

Deleting a role:

• Removes the role from every member who held it. Those members keep any other roles they had.
• Owner role can't be deleted — see protection above.

Best practices

• Build a small set of common roles, reuse them across teams. Two or three propagating roles + a handful of non-propagating ones cover most setups.
• Don't build per-person roles — that's what overrides are for. A role meant for one person tends to drift.
• Review periodically. Permission inflation is real — re-check what each role grants every few months and trim.