Permissions model

Dashboard access is controlled by access roles. Each staff account has one role, and each role defines the features that person can open and how much they can do there. Build roles in Staff → Access roles.

The parts of an access rule

Feature

What the rule applies to. Features include Staff access, Customers, Staff directory, Shifts, Sessions, Reservations, Locations, Memberships, Payments, Reports, studio settings, and other dashboard areas.

Access

How much the role allows:

• Read: view data without changing it.
• Write: view, create, update, and delete data. When Locations or Sessions use a selected boundary, Write excludes creation because a new record does not belong to the saved selection.

The dashboard stores these levels using the API's existing action grants. This keeps API keys and older custom roles compatible. If an older role contains a narrower combination of actions, opening and saving it without changing the access level preserves that combination.

Applies to

Most access applies to the Entire studio. A small set of features can be limited because the API enforces those boundaries:

• Locations and Reports can apply only to selected locations. Locations offers this boundary for Read and Write.
• Sessions and Reservations can apply only to selected sessions. Sessions offers this boundary for Read and Write.

The role editor shows these choices only for features and access levels where they affect runtime authorization. New or changed selected boundaries must include at least one location or session. Untouched legacy grants keep their stored boundary.

Full studio access

The Owner role holds Everything, Write, Entire studio. Owners can do everything, including the sensitive customer Staff Actions described on Customer profiles. Any other role given Everything at Write gets the same, including Log in as customer and Customer account recovery, so name the areas a role needs instead when it should not have those.

Log in as customer

Log in as customer (customer-impersonation) lets staff open a customer's account portal as that customer for a 15-minute support session. The session can look but not change anything: bookings, payments, cancellations and other changes are refused, and staff who need to act for the customer do it in the dashboard instead. Removing the access from a role ends any session its staff still have open.

Only the Owner role has it by default. To let other staff use it, for example counter staff who help customers in person, add Log in as customer at Write to their role. Every session leaves a note on the customer naming the staff member who opened it.

Customer account recovery

Customer account recovery (customer-account-recovery) decides who a customer account answers to. With it, staff can:

• generate sign-in links that sign the customer into their account,
• set the account's email address without either mailbox confirming, and
• merge away a customer record whose email address was confirmed.

This is a stronger grant than Log in as customer. A sign-in link opens a full customer session that can book and pay, and it keeps working after the access is removed from the staff member's role. A changed address hands the account to whoever holds the new mailbox. Grant it only to staff you trust with the account itself.

Only the Owner role has it by default. Every use is recorded in the audit log against the staff member who did it, and setting an address also leaves a note on the customer naming that person.

Credit balances

Setting a credit balance outright needs Memberships at Write, the same access that can already assign a customer a membership. The default Manager and Front Desk roles have it. Viewing the history of balance changes needs Memberships at Read.

Granting customer access from another role

A staff member can only grant access their own role holds. Someone who can edit roles but does not have Log in as customer or Customer account recovery cannot give either one to anyone, including themselves.

Permission-gated areas

Most screens are visible to any signed-in staff member, but some are hidden without the required access:

• Bans: requires bans:read (the page also blocks its content without it).
• Help: requires support-tickets:read (the page also blocks its content without it).

System roles

Some roles are built in and badged System. They cannot be deleted, and a role cannot be deleted while staff accounts are still assigned to it.

Tips

• Give each role the least access it needs. Start with Read, then raise it only where the job requires changes.
• Use selected locations or sessions only when someone must be kept inside that part of the studio. Otherwise, keep Entire studio.