Permissions

Permissions in Level are attached to nodes in the organization tree (Organization → Team → Sub-team). What a user can actually do at any given node is the combination of:

1. Roles they hold there (or at a parent node, if the role propagates).
2. Permission overrides specifically granted or denied for them.

The Effective permissions summary on a member's access dialog shows the final answer for that person.

Permissions vs object access

One distinction drives the whole model:

• Permissions decide what you can create and configure — create ad accounts, manage segments, build reports, edit organization settings.
• Access to things that already exist — reports and ad accounts — is granted separately, from the role, on its Reports access and Ad accounts access tabs. Grants are batched: tick many reports or set levels on many ad accounts, then save once.

Ad accounts have three access levels: No access, Can view, and Can control (view plus start/stop sync).

Two permissions govern who can hand out that access: Manage Report Access and Manage Ad Account Access.

Practical upshot: a viewer role can have zero permissions and still open specific reports — you just grant those reports on its Reports access tab.

The catalogue

Level ships with a fixed list of permissions, grouped in two sections:

• Administration — managing organization settings, teams, roles, and who can access reports and ad accounts.
• Data & Reports — creating ad accounts, managing metrics, segments, campaign tagging, reports, and content analytics.

These sections are how the Roles → Permissions editor groups the toggles. You can't add new permissions; admins build new roles that combine existing ones.

Roles vs overrides

Two layers, applied in order:

1. Roles are reusable bundles. A user holds zero or more roles at each node, and each role grants a set of permissions.
2. Overrides are user-specific tweaks: explicitly grant or deny one permission for one user at one node, on top of what their roles say.

The recommended pattern: express access through roles. Use overrides only for edge cases where a single person needs a one-off adjustment that doesn't justify a custom role.

Propagation

Each role has a propagate to child teams toggle:

• On — the role applies at this node and every team / sub-team below it.
• Off — the role applies only at the node it's assigned to.

Turn it on for "global" roles like an organization-wide admin. Turn it off for team-specific roles that shouldn't bleed into sibling parts of the tree.

The Owner role always propagates — Owners have every permission everywhere, regardless of any toggle.

How Level decides "can I do this?"

When you try to take an action, Level resolves your effective permissions like this:

1. Gather every role you hold at this node, plus every propagating role you hold at parent nodes.
2. Union all the permissions those roles grant.
3. Apply your overrides:
   • Deny removes a permission.
   • Grant adds a permission.
   • When the same permission is overridden at multiple nodes (e.g. team and organization), the closer node wins.
4. If you're an Owner anywhere in your tree, you get every permission unconditionally.

The result is the set of things you can do at that scope. Access to individual reports and ad accounts is then read from your roles' Reports access and Ad accounts access grants.

In this section

• Roles — creating and editing roles, the Owner role, propagation, object access tabs.
• Catalogue — every permission in the catalogue, by section.
• Overrides — when (and when not) to use them.