Roles and Permissions

Roles control what your staff can do in Booking Phoenix — take bookings, refund payments, manage rooms, view reports, configure the branch. Each user is assigned one or more roles, and their effective permissions are the union of every role they hold. This guide covers creating roles, editing them, and assigning them to staff.

Opening the permissions page

Go to Settings → Permissions. You'll see a list of every role at your tenant with a count of users in each.

Built-in roles

Most tenants start with a few sensible defaults:

• Owner — full access. Reserved for owners and senior managers.
• Manager — everything operational (bookings, refunds, customers, reports) but not billing or destructive admin actions.
• Front Desk — take and check in bookings, view customer records, see today's calendar. No financial settings, no user admin.
• Game Master — check-in flow, score entry, customer notes. Read-only on the rest.

You can edit these defaults or create new roles from scratch.

Creating a new role

1. Click Create Role on the permissions page.
2. Give it a name (e.g. "Marketing Lead", "Bookkeeper").
3. Tick the permissions the role should have.
4. Save.

Permission categories

Permissions are grouped into categories so you can grant a whole area at once:

• Bookings — create, edit, cancel, reschedule, check in.
• Payments — take payments, issue refunds, view payment history.
• Customers — view records, edit details, merge duplicates, deactivate, export data.
• Vouchers — issue, redeem, void, edit templates.
• Rooms — create rooms, edit rooms, manage schedules, manage pricing.
• Reports — access reports, export data, build custom reports.
• Branch settings — edit branding, currency, tax, email templates, notifications.
• User administration — create staff users, assign roles, manage permissions, reset PINs.
• Integrations — configure Stripe, third-party apps.
• Subscription / billing — view invoices, change plan, update payment method.

Granular permissions

Inside each category, individual permissions let you fine-tune. For example, in Payments you might give Front Desk "take payment" but not "issue refund" — refunds escalate to the manager on shift.

Assigning roles to a user

1. Go to Users and click the user you want to update.
2. Click Edit.
3. In the Assigned roles field, click and select roles from the dropdown. Multiple selections allowed — permissions stack.
4. Save.

The user's permissions take effect on their next page load — they don't need to log out and back in.

Auditing permissions

To see who has access to what:

• The Permissions page shows each role and its user count. Click a role to see members.
• Each user's profile shows their assigned roles.
• Reports → Auth Log records every login and user switch — useful for "who could have done X" investigations.

Practical patterns

Least privilege as the default

Start every new staff member on the most restrictive role that lets them do their job. Add permissions as needs come up rather than over-granting from day one. It's much easier to add than to revoke after the fact.

Separate financial actions

Refunds, voucher voiding, and changing payment provider settings are common targets for fraud or accidental misuse. Reserve these for managers and above — not because front-desk staff are untrustworthy, but because errors are costly to reverse.

One role per actual job

Resist the temptation to create a unique role per person ("Sarah's role"). Roles should map to job functions — "Front Desk", "Manager", "Owner". When Sarah leaves, you don't have a stale role to clean up.

Removing access when staff leave

When someone leaves the team, don't delete their user account — their booking and payment history would become hard to attribute. Instead:

1. Open their user profile.
2. Toggle Account active off.
3. Save.

They lose login access immediately. All their historical actions stay attributed to them.

Locking yourself out

It's possible to remove your own User Administration permission and lose the ability to grant it back. If this happens:

• Another user with User Administration access can grant it back.
• If no one has it, contact support — we can restore it for you.

To prevent this scenario, keep at least two people with full Owner-level access at all times.