# 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 |
| `reports.view_all` | See figures for the whole business |
| `reports.view_own` | See only their own figures |
| `settings.access` | Open the settings area |
| `addons.manage` | Switch add-ons on and off |
| `members.is_bookable` | Whether this role is listed as a service provider |

## 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.

## 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".