A permission is the right to perform one precise action on one type of object in the Console — viewing your dashboards, publishing a screen, deleting a plan. Purchasely ships 84 of them, grouped into 8 categories.

You never have to assemble those 84 permissions yourself. A role is a ready-made bundle of permissions that you pick when you invite a teammate, chosen so that it matches how people actually work: someone who only needs to read reports, someone who builds and publishes paywalls, someone who wires up the SDK.

The six roles

Assigning a role

Roles are managed from Users & Access: click your name in the bottom-left corner of the Console, then Users & Access.

You choose the role when you send the invitation, and you can change it at any time afterwards — the new role takes effect immediately, on the teammate's next request.

App-level access is a separate control that still applies on top of the role. For each team member you decide whether they reach all your apps (including apps created later) or only a specific list. A teammate only ever sees the apps they have access to, and their role then decides what they can do inside those apps. An Editor limited to one app can publish screens in that app and nowhere else.

What each role can do

Below is the full list of permissions, grouped by category, with what each role grants.

Permissions in bold are critical: everything that permanently removes an object (Delete) and everything under Account (billing, team management, API keys, app creation). Grant them deliberately.

Internally each permission is identified by a category.object:action string — you will see this shape in the Management API, in MCP consent screens and in audit logs. In the Console you only deal with the human labels used below.

Analytics

Experiences

Targeting

Experimentation

Look-ups

Setup

Integrations

Account

📘

Custom permissions require an Enterprise plan

The five ready-made roles above — Read-only, Support, Editor, Developer and Full admin — are available on every plan, at no extra cost. Picking permissions one by one — the Custom role — is an Enterprise feature. If you need a bundle that none of the five presets covers, please contact our team to enable it on your account.

Guardrails

A few rules apply whatever role you use:

• You can only grant permissions you hold yourself. You cannot give a teammate — or an API key — a permission that is not in your own set. A Developer cannot promote someone to Full admin, because a Developer does not hold the billing permission.
• Critical permissions are flagged. Deletes and everything under Account are marked as critical in the permissions editor, so an over-broad grant is visible before you confirm it.
• Read-only account access is reversible. An account can be switched to read-only, which narrows every one of its administrators to view-only across the whole Console, whatever their role. Their stored permissions are untouched — they are only ignored while the switch is on, so turning it back off restores everyone's write access exactly as it was. This is how we make sure nothing is ever written to your Console during a support investigation.
• Changing a teammate's role rewrites their whole permission set. Roles are bundles, not additions. Moving someone from Developer to Support replaces their 83 permissions with the 5 in Support.