Roles and permissions

Permissions in Bookodile are attached to roles, and roles are yours to define. There is no fixed ladder of job titles — you build the roles your business actually has and give each one the permissions it needs.

The permissions

The view-all / view-own pairs

Three areas come in pairs — bookings, customers and reports — and the pair is the important part.

view_own is a genuine restriction, not a default filter someone can widen. Someone with reports.view_own sees their own numbers and cannot reach a colleague's, including through a link someone sends them.

This pair also governs money. Whether a team member can see everyone's tips is decided by whether they can view all reports or only their own.

The one that is not about access

members.is_bookable — labelled "List as a service provider" — does not grant or restrict anything. It says whether people with this role appear on your booking page as someone a customer can choose.

It lives with the permissions because it is a property of the role rather than the person: front-desk staff, managers and owners who do not personally deliver services all sit in roles that are not bookable.

Turning it off does not reduce anyone's access. Turning it on does not grant any.

Reading messages and sending them

messages.send decides who may write to a customer from Messages. It is on in every role unless you switch it off. Reading a conversation does not need it: anyone who can see the customer can read their conversations, so a role limited to its own customers reads only those customers' messages.

Switched off, the person still reads the conversation and is told plainly that their role does not send; the compose box and New message are not offered.

Reading the activity log

Activity has no permission of its own: each person reads the history of what their role already shows them. Someone who sees only their own bookings sees only those bookings' history; customers' cards need access to every customer; the team's changes need the team permission; settings changes need Settings. Each person always sees changes to their own hours and time off, and the owner sees everything.

Reading the team's AI chats

Everyone can use AI Chat, whatever their role: what it reads and changes for them follows their own permissions. A person's chats are their own.

ai_chat.view_all — "Read the team's AI chats" — lets someone open their colleagues' chats as well. It is on for the Owner and Manager roles and off for the others; a role you create starts without it. The workspace owner always has it.

• Read only. Nobody can write in someone else's chat, and only its author can delete it.
• The branch you're working in. Chats started in All branches are the workspace owner's to read, no one else's.
• Never more than your role could see. A chat is a copy of what it read with its author's access, so a chat that read something your role can't see stays hidden from you — a colleague's chat about their own bookings needs you to see everyone's bookings.

A worked example: a salon owner reads the chat in which a new manager changed the Saturday hours, to see what was asked and what was applied; a clinic keeps it off for a receptionist role, so the practitioners' chats about their own patients stay theirs.

Billing

billing.manage opens Settings → Billing — the plan, the card and invoices — and lets someone raise the monthly SMS cap, for the whole workspace, every branch included. It is one answer everywhere: someone whose role has it at one branch has the workspace's billing from any branch they work at, and from All branches.

The Owner role always has it, and so does the workspace owner, whatever their role says. Every other role starts without it.

Only the workspace owner can give it. Turning billing.manage on or off for a role, putting someone on a role that has it, and inviting someone on such a role to sign in are the owner's alone, because who handles money is your decision to make on purpose. A manager who can edit roles and the team still cannot hand billing to anyone, themselves included — on the role screen they see the switch, greyed out, with the reason. Moving someone off such a role, or deactivating them, is an ordinary team change.

Billing emails — payment problems, SMS nearing or reaching the cap — still go to the owner only.

A worked example: a salon owner who leaves the books to a bookkeeper gives a "Bookkeeper" role billing.manage and nothing else; a gym with a front-desk manager who pays the bills turns it on for the Manager role.

Ownership

The business owner is not a role you can edit away. Ownership carries full access regardless of what roles exist, so you cannot lock yourself out by misconfiguring one.

Organisations and branches

Roles belong to a business. In a multi-branch organisation, someone's access is scoped to the branches they are a member of — being on the team at one location does not grant sight of another's bookings or figures.

Worked example

A three-person clinic.

• The owner — everything, and not editable.
• Practitioner — bookings.manage, bookings.view_all (they cover for each other), customers.view_own, reports.view_own, listed as a service provider. They can see the whole diary but only their own patients and their own numbers.
• Reception — bookings.manage, bookings.view_all, customers.view_all, no reports, not listed as a service provider. They run the diary for everyone and appear to no customer as a bookable person.

Limits

• Permissions are per role, not per person. Someone needing different access needs a different role.
• One role per person per branch.
• There is no per-service permission. Access is not scoped to a subset of the catalogue.
• view_own cannot be widened temporarily. There is no "show me everything just this once".
• Billing is all or nothing. There is no "see invoices but not change the card".
• Only the workspace owner gives billing. Someone who manages billing cannot pass it on to anyone else.
• The Owner role cannot be edited, and it always includes billing.
• Billing emails go to the owner only, even when others manage billing.