For OrganizationsPeople & Permissions

Roles and what each one can do

6 min read Updated October 25, 2026Last reviewed October 25, 2026

Every organization is created with eleven roles already set up. What a role can do is a list of permissions, and a member’s access is the sum of the permissions on the roles they hold.

How a permission works

A permission is a module × level pair — Bookings · Approve, Reports · Export, Settings · Administer. There are 14 modules and 7 levels, so a role’s grid is a set of ticked boxes.

Three rules follow from that, and they explain most of what you’ll see:

  • Permissions are additive. A member can hold more than one role, and they get the union of all of them. There is no “deny” — you can’t take something away by adding a second role.
  • Only active members have any permissions. Someone who has been invited but hasn’t accepted yet has none at all, and neither does anyone who isn’t an active member.
  • A level does not imply the ones below it. Edit without View is a grid you can tick, so read the row, not just the highest box.

The 14 modules: Organization · Members · Locations · Spaces · Programs · Events · Bookings · Marketplace · CRM & Contacts · Messages · Reports · AI · Billing · Settings.

The 7 levels: View · Create · Edit · Delete · Approve · Export · Administer.

The default roles

This is what each role holds the day your organization is created. Everything except the Owner row can be changed.

RoleModules (besides Members)LevelsMembers
OwnerAll 13All 7 — View, Create, Edit, Delete, Approve, Export, AdministerView, Create, Edit, Delete
ExecutiveAll 13View, Create, Edit, Approve, ExportView, Create, Edit, Delete
General ManagerAll 13View, Create, Edit, Approve — plus Export on Reports, Events and LocationsView, Create, Edit, Delete
Entertainment DirectorPrograms, Events, Bookings, Marketplace, CRM & Contacts, Messages, Reports, AIView, Create, Edit, Approve — except Bookings: View, Create, Edit (no Approve, so it can't sign booking agreements unless you grant it)View
Operations ManagerLocations, Spaces, Programs, Events, Bookings, ReportsView, Create, EditView
Marketing ManagerMarketplace, CRM & Contacts, Messages, Reports, AIView, Create, Edit, ExportView
Finance ManagerBilling, Reports, BookingsView, Approve, ExportView
Location ManagerLocations, Spaces, Programs, Events, BookingsView, Create, EditView
Team MemberPrograms, Events, Bookings, Messages, ReportsViewView
Read OnlyAll 13ViewView
GuestEvents, MessagesViewView

Bookings · Approve also signs booking agreements. By default only Owner, Executive, General Manager and Finance Manager hold it.

Read the table as a grid: Executive holds five levels on all thirteen of those modules, so it has Marketplace · Approve and Billing · Export and everything else in that rectangle — but it does not hold Delete or Administer on any of them.

Out of the box, only the Owner role has Settings · Administer. Executive, General Manager and Read Only can open Settings (they hold Settings · View), but none of them can administer it.

Members is its own permission column: View (see the member list), Create (invite), Edit (change a member’s role) and Delete (remove a member — not available yet). Owner, Executive and General Manager hold all four by default; every other role holds Members · View. Inviting and changing roles follow your own permissions: you can give only a role whose permissions you hold yourself, and never Owner. See Inviting people to your organization.

The Owner role can’t be edited

Owner always keeps full access, and the screen says so:

The Owner role has full access and can’t be edited.

Its checkboxes are locked, the server refuses an edit to it, and the database refuses to remove its administrative permission. That’s the recovery anchor: it means an organization can never end up with nobody able to manage permissions.

Changing what a role can do

Settings → Permissions. You need Settings · Administer; without it the panel shows an explanation instead of the editor:

Managing roles and permissions requires the Settings · Administer permission. Ask an organization owner or admin to make changes.

Choose a role from the Role dropdown, then tick or untick boxes. Nothing changes until you press Save: you are shown exactly what will change (“+ Bookings · Approve”, “− Reports · Export”) and asked to confirm, and the whole role is saved at once. Discard throws your edits away. Saved changes apply to everyone holding that role.

A role whose permissions differ from its default is marked Modified. Restore to default puts that one role back to the defaults in the table above, after a confirmation listing what changes — it never touches any other role. A save or restore that would leave nobody able to manage the organization is refused.

Two things that surprise people

Both of these are working as built. Neither is a bug, and knowing them in advance saves a support ticket.

Billing is gated on Settings · Administer, not on the Billing module. So the Finance Manager role — which holds Billing · View, Billing · Approve and Billing · Export by default — still cannot open Settings → Billing. They get:

You don’t have access to billing for [your organization]. Ask an organization admin.

If you want a finance lead to manage the subscription, you have to grant their role Settings · Administer, and that is full administrative access, including the permissions editor. There is no narrower grant that opens Billing on its own.

The default invite role cannot open Settings at all. Team Member — what the invite dropdown picks unless you change it — holds View on Programs, Events, Bookings, Messages and Reports, and nothing on Settings. So a newly invited team member has no Settings item in the sidebar. Every member can now see their own role under Settings → Account & security (“Your role: …”), which is open to every member.

What this does not do yet

You can’t create a role. The eleven roles above are created automatically with the organization, and there is no action anywhere in the workspace to add, rename, duplicate or delete one. The editor shows a Custom tag next to any role that isn’t part of the built-in set, but nothing in the product can produce one. What you can change is what each existing role is allowed to do — which in practice covers most of what a custom role would have been for.

There’s also no way to see, from a role, which members hold it — the Members roster reads the other way round, member to roles.

Was this article helpful?