Your organization

Roles and permissions

Member and administrator are often enough. When they are not, create your own roles and tick exactly what each one may do.

Updated on August 14, 2026

How authorisation works

Three principles explain almost every behaviour.

A person holds a role within an organization; that role carries a set of permissions.
A permission describes a precise action on a resource: view invoices, issue an invoice, send a message, manage third parties.
Some permissions imply others — being able to manage assumes being able to view. You do not have to tick both.
Enforcement happens server-side, not just in the interface. Hiding a button is never the only protection.

Built-in roles

Available from the moment the organization is created.

Owner — the person who created the organization, with the same prerogatives as an administrator.
Administrator — runs the organization: members, roles, subscription, settings, firm connection.
Member — works inside the organization within the permissions granted to them.

Creating a custom role

Three steps from the Roles tab in settings.

1
Name the role
A name that means something to your team — “Accounting”, “Management”, “Assistant” — whose technical identifier is derived automatically.
2
Tick its permissions
The catalogue is grouped by area: folders, documents, tags, conversations, messages, invoicing, purchases, bank accounts, accounting, third parties. Each permission states what it allows.
3
Assign it
The role becomes selectable on every member's record, just like the built-in ones.

Warning

A role cannot be deleted while members still hold it: reassign them first, and the deletion then has no side effect.

Permissions and modules

Some permissions only make sense if the matching module is active. Invoicing permissions, for instance, only appear for an organization that holds the Invoicing module. The module opens the surface, the role decides who reaches it: both conditions must be met.

Tip

If a member cannot see a section you thought you had opened to them, check the module first, then the role.

In practice

Start tight and widen on request: it is easier than taking back rights already granted. Keep the administrator role for people who genuinely have to run the organization — reaching invoicing or documents does not require it.