---
title: "Roles and permissions — React Box documentation"
description: "Built-in roles, custom roles and the permission catalogue: who can do what in your organization."
url: https://www.react-box.com/en/docs/organization/roles
lang: en
---

Your organizationRoles and permissions

# 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 September 11, 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. Analytics permissions, for instance, only appear for an organization that holds the Analytics 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.

## The “Archive documents” permission

This permission governs the whole of vault archiving: filing documents into an archive, taking them back out, renaming or deleting an archive, and above all seeing archived paperwork. Without it, an archived financial year simply does not exist for that member — not in folders, not in search, not through a direct link. It assumes the right to view documents, so you do not have to tick both.

Note

Administrators and owners hold it by default. So does your accounting firm on its clients' files: its ability to archive comes with the organizational link and is not set anywhere.

## What follows the role, not a permission

Two capabilities are absent from the permission catalogue and will stay absent: the Atlas assistant and MCP connections. Both read the whole file — invoicing, bank, vault, members, subscription — rather than one area, so they follow the administrator role and nothing else. A custom role cannot tick them, and a role created before this change has lost them.

Administrators only

To give someone Atlas, or the right to connect an agent, make them an administrator. There is no middle ground, and that is deliberate.

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