Staff & permissions

Create dedicated accounts for your team and use roles to control exactly who may see and edit which areas. This way everyone works with the permissions they need for their task — no more and no less.

Invite staff

In the sidebar, open Staff and click Invite staff.

1. Enter the first name, last name and email address.
2. Assign a role that determines the permissions.
3. The invitation goes out by email; the status changes from "Invited" to "Active" as soon as the person accepts it.

Roles & permissions

Via Roles & Permissions you create roles and set the permission per page or module: no access, view only or edit. The modules are arranged in groups (operations, my restaurant, settings and extras). Using the quick switches you set all modules at once to view, edit or no access.

Reservations

The Reservations permission covers the booking list, the detail pages, the calendar view and the booking export. With View only all of that stays readable, but the buttons are gone: creating, walk-ins, confirming, rejecting, cancelling, no-show, assigning tables and editing notes require Edit. The same applies to walk-ins from the live floor plan and the post-visit notes from the day view — they write to the same booking.

Invoices & payments

The Extras group holds the Invoices & payments permission. Use it to hand billing over to a member of staff without handing over the owner account:

• View only: the Invoices and Payments menu items are visible and the invoice PDFs can be opened.
• Edit: additionally cancel an invoice, send it again, mark it as refunded, download the invoice journal and the PDF archive — and in the booking list mark a booking as paid or create an invoice.
• No access: both menu items are gone, and the booking list only shows the payment status — without a button.

The booking export (CSV) belongs to the Reservations permission; it only includes the Amount, Paid on, Payment method and Invoice no. columns if the role may at least view "Invoices & payments" as well.

The invoicing profile and the payment providers stay reserved for the owner: tax, bank and access details sit behind them. That is why the menu entry Settings → Invoicing only appears in the owner's menu.

Day view, floor plan live & floor plan management

The day view has its own permission. With View only it shows the table grid, and a click on a booking opens its detail page (provided the role may view reservations). Dragging, changing the duration, quick create and the edit dialog require Edit. Floor plan live is a pure display: walk-in only appears if the role may edit reservations, the edit dialog only with Day view: Edit. For floor plan management (My restaurant), View only shows the overview; the editor, creating and deleting tables and sorting the rooms require Edit.

Waiting list, messages, templates, guests, reviews & loyalty

These six areas each have their own permission. With View only the entire content stays readable — entries, conversation histories, template texts, tags, reviews including replies, and the loyalty programme with its tiers and rewards. What disappears is only the buttons that would change something: in the waiting list create, offer a table, cancel and the internal note; for messages reply, close, reopen and new message; for templates create, edit, delete and the default templates; for guests creating and changing tags; for reviews reply, publish, hide and report; for the loyalty programme every field of the configuration, tiers and rewards.

Two places deliberately reach beyond their own area:

• Waiting list → booking: "Convert to reservation" creates a real booking and therefore also requires Reservations: Edit. Otherwise the waiting list would be a way around the reservation permission. Offering a table and cancelling still need only the waiting-list permission.
• "Message the guest": the button appears in several lists — reservations, guests, the waiting list and event bookings. It always belongs to the messages permission, not to the list it sits in, and shows only with Edit on it.

The template picker in the reply and offer dialogs reads templates and therefore requires Templates: View only; without it the dialog stays usable, just without the template list. The placeholder reference is a pure look-up page and is open to anyone who may view templates.

My restaurant, media & menu

The My restaurant permission covers the profile, the photos and the media library; the menu has its own. With View only everything stays readable: in the profile every field shows its value, just locked, and the menu shows categories, dishes, prices, tags and availability unchanged. Only the buttons for saving, uploading, creating and deleting are missing. Two controls deliberately stay for everyone because they save nothing: the EN toggles in the profile, which show and hide the translation field, and the language switch above the menu.

Three places deliberately reach beyond their own area:

• Pick an image from the library: the picker in the menu, events and marketing reads the media library and therefore needs My restaurant: View only. Someone who may edit the menu but not see the library can still change everything else about a dish — only the image button is missing.
• Preview in the profile: it shows the state of the edit form and therefore belongs to Edit. With view only, the same page is one button to the right under View live — in its saved state.
• Creating the business: the setup page deliberately checks no permission. While no business exists there are no permissions to attach it to; as soon as one exists the page redirects straight to the profile and cannot change anything there.

The device list under settings is read-only and belongs to the settings permission: it shows which devices are registered and whether the last push arrived. Registering and unregistering is done by the app itself.

Events

The Events permission covers the event list, the event form and the booking list. With View only, the list and the bookings stay fully readable — title, date, type, price, occupancy, status and every attendee with their paid state. What disappears are only the routes that would change something: New event, the pencil for editing, the title link into the form, pausing and resuming, and the bulk message button and dialog in the booking list.

Two controls in the booking list belong to another area and are gated separately: Mark as paid and Create invoice produce a document and require Invoices: Edit; the paid state itself stays visible as a fact about the booking. “Message the guest” hangs, as everywhere, on Messages: Edit.

Subscription, setup and the upgrade page

A few areas deliberately do not hang on the permission system but on the owner — a checkbox in the role editor would be the wrong question there:

• Subscription: booking, cancelling, changing billing details and the payment portal are commercial commitments of the business. Only the owner gets in, and the menu item is therefore not shown to staff at all, rather than ending on an error page.
• Billing profile and payment providers: owner's business as before — tax, bank and access details sit behind them.
• Setup wizard, "not applicable" and hiding the checklist: hiding the checklist for everyone or declaring a step done is a decision about the setup of the business, not about your own view. The progress itself stays visible to everyone, as does every step link.
• Resetting demo data: deletes sample data — not for reception staff.

Conversely the upgrade page ("more online tables") deliberately stays open to everyone in the partner area. It only shows the public price tiers and your own usage, and so explains why a limit has been reached. Booking does not happen there but in the subscription — and that is where the barrier sits.

Settings, POS, widget, reports and support

The booking settings, the POS connection, the email templates and the support requests all belong to the settings permission; the widget, the reports and the dashboard each have their own. With View only everything stays readable: every setting shows its value, just locked, and the POS mapping, allowed domains, template list and request history are fully visible. Only the buttons for saving, creating and deleting are missing. Controls that save nothing stay for everyone: the tabs on the settings page, search, filter and sorting in the POS mapping, and the email template preview.

Two places are deliberately stricter than they would strictly need to be:

• The suggestion lists in the POS editor ("which table matches this POS name?") require Edit. They belong to the mapping — as read-only endpoints they would be a side door to the table list for someone who may see settings but not tables.
• The connection test to the POS also requires Edit. It triggers a signed call using the business's key; since it has no button of its own, nothing disappears from the interface as a result.

The POS key is only ever shown masked anyway — in clear text it appears once, right after it is generated. The reset demo data card on the dashboard belongs to the role, not the permission (see above).

Guest records

The guests permission covers the guest list, the guest record and the tags. With View only the whole record stays readable: contact details, visit history, tags, allergies, preferences and internal notes show their values, just locked. The CSV export stays too — it outputs exactly what the list already shows. Only creating, editing, the VIP switch and the import from existing bookings are missing; the VIP status itself remains visible as a star, since it is a fact about the guest.

Important for daily work: the name search that offers suggestions when creating a booking, in the day view, the floor plan, group bookings, coupons and messages belongs to this permission as well — it hands out the name, email and phone number of stored guests. Someone who may not see guests gets no suggestions there any more; the fields can still be filled in by hand, and booking works unchanged.

Manage

You edit existing staff in the list, deactivate them temporarily or remove them entirely. Deactivating keeps the account but blocks sign-in, which is useful for seasonal staff. The owner account always has full access and cannot be restricted, so at least one person always retains complete control of the business.