Roles and custom permission bundles

Who this is for: Owner — requires org.roles.manage. Where: Settings → Roles

A role is a named bundle of permissions. Your organisation starts with six — Owner, Manager, Front Desk, Accountant, Storekeeper and Read-only — and you can author as many more as the shape of your house needs.

Roles are organisation-wide. Where a role applies is decided when you assign it, on Members, not here.

Six default roles. Owner is the one with no Edit and no delete — only Clone.

Tip

Before authoring anything, read Roles and what each one can do. Most houses need one or two narrow roles on top of the defaults, not a replacement set.

Create a role#

1. Open Settings → Roles.
2. Select New role.
3. Enter a Name — what a colleague would call the job. "Night Auditor", not "role-3".
4. Tick the permissions this role should carry. The catalog is grouped by owning app, and each entry shows what it allows above its permission key.
5. Select Create role.

Author a role by name and by ticks. The count is the fastest way to notice you have ticked forty things.

The count beside Permissions tracks what you have selected as you go, which is the fastest way to notice you have ticked forty things when you meant to tick two.

The catalog is grouped by owning app, and every entry shows what it allows above its permission key.

Tip

Author narrow roles and let them add up. Somebody who needs to check guests in and nothing else gets a role with frontdesk.checkin and frontdesk.reservation.read; if they later also need the ledger, give them a second membership rather than widening the first role for everybody who holds it.

Clone a role#

1. On the role you want to start from, select Clone.
2. The dialog opens pre-ticked with that role's permissions and a name ending in copy.
3. Rename it, adjust the ticks, and select Create role.

Clone is how you make a variant of a default role — "Manager, but without payments" — and it is the only way to build on the Owner role, which cannot be edited.

Edit a role#

1. On the role, select Edit.
2. Change the name or the ticks.
3. Select Save changes.

The change applies to everybody who holds that role, immediately, wherever it is assigned. Nobody signs out and back in.

Warning

Editing a role you hold yourself changes your own menu as soon as you save. If you remove a permission your current screen needed, the screen you are looking at is the one that goes away.

Delete a role#

1. On the role, select the bin icon.
2. Confirm.

A role that is assigned to somebody cannot be deleted — the attempt is refused rather than silently stripping people's access. Remove the memberships on Members first, then delete the role.

What the Owner role will not let you do#

Owner is reserved. It resolves to the entire permission catalog, and it is the one role with no Edit and no Delete — only Clone. That is deliberate: Owner is what the last-Owner safeguard protects, and a role that could be edited down to nothing would be a way around it.

Two more refusals worth knowing before you meet them:

What you tried	What happens
A name another role already uses	Refused — role names are unique in an organisation
A permission that is not in the catalog	Refused — the catalog is the whole vocabulary, and it is not extensible from here

A permission whose app is switched off does nothing#

Ticking a permission grants it. It does not guarantee the screen appears: the app that owns the permission also has to be enabled on the property. A role holding every rms.* permission still shows no Revenue menu on a property where Revenue is off — and the refusal looks exactly like not holding the permission at all.

This is the most common reason a freshly authored role "doesn't work". See Enabling apps for a property.

What's next#

• Members and invitations — assigning the role, and at what scope
• Roles and what each one can do — the default bundles and the permission behind every screen
• The audit log — role creation and edits are recorded there