# Roles and permissions

> What each permission actually controls, the view-all versus view-own pairs that decide whether someone can see colleagues' data, and the one permission that is not about access at all.

_Last verified: 2026-09-05. Source: https://bookodile.com/docs/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

| Permission | What it allows |
|---|---|
| `bookings.manage` | Create, edit, cancel and move bookings |
| `bookings.view_all` | See everyone's bookings |
| `bookings.view_own` | See only their own |
| `customers.manage` | Create and edit customer records |
| `customers.view_all` | See every customer |
| `customers.view_own` | See only customers they have served |
| `services.manage` | Create and edit services and prices |
| `team.view` | See the team list |
| `team.manage` | Add, edit and deactivate team members, and manage roles — except who has billing, which is the owner's |
| `reports.view_all` | See figures for the whole business |
| `reports.view_own` | See only their own figures |
| `settings.access` | Open the settings area — add-ons included: switching them on and off, their settings, and their tools such as vouchers, discount codes and the waiting list |
| `members.is_bookable` | Whether this role is listed as a service provider |
| `messages.send` | Write to customers from Messages, by email and SMS |
| `billing.manage` | The workspace's billing: plan, card, invoices and the monthly SMS cap |
| `ai_chat.view_all` | Read the team's AI chats — read only |

## 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](/docs/activity-log) 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.