ThirdSectorBee uses a fine-grained permission model rather than fixed roles. Every team member is granted a specific set of permissions, and the platform’s behaviour is the sum of those grants.

The shape of a permission key

Permissions follow the pattern module:action:resource. For example:

  • relationships:read:contacts — read contacts in the Relationships module
  • account:admin:team — administer the team in the Account module
  • tickettailor:sync:initiate — trigger a sync in the TicketTailor integration

The structure means new permissions can be added per module without changing the model, and reading a permission tells you what it does without needing a separate lookup.

Why fine-grained, not roles?

Charities differ enormously in how they split work. A two-person operation has one person doing everything; a national charity has volunteers who only see touchpoint history, fundraisers who manage donations, and finance staff who handle Gift Aid. Fixed roles (“Editor”, “Admin”, “Viewer”) force every charity into the same shape.

By contrast, fine-grained permissions let an administrator say exactly who can do exactly what — and add permission bundles later if a “role” pattern emerges naturally.

Special permissions

A few permissions sit outside the normal model:

  • sysadmin:admin — full platform administration. This is reserved for ThirdSectorBee staff and cannot be assigned through the workspace UI.
  • relationships:manage_contact_access — controls who can edit field-level access restrictions on individual contacts. See Restricting access to contact details in Create and edit contacts.

Field-level access

Beyond what a user can do, ThirdSectorBee can restrict what a user can see on individual contact records. Sensitive fields (address, contact details, consent records) can be hidden from teams that don’t need them, while keeping the contact’s name visible everywhere — so they still appear in lists and relationship graphs.