Roles & Permissions

Every person in your organization holds one or more roles, and each role decides which pages they can see and what they can do on them. This page lists the built-in roles, exactly what each one can access, and how to set up accounts for testing or day-to-day work.

The built-in roles

The five project roles are explained in Project Roles, and the three sales roles in Sales Roles.

Roles are presets, not hard limits — administrators can also tune access per page, per person on the Team & Access page (see User Management (Team & Access)).

What each role can access, page by page

Access on each page is expressed as a simple level: No access (the page is hidden entirely), Viewer (read-only), Preparer (Draft) (create and submit drafts, and request reversals of posted records), Reviewer (review/reject), Approver (review, reject, and approve — though not both review and approve the same record), Full access (everything on the page), or — for configuration pages — Manager (change settings). These are the exact labels shown on the Team & Access page.

The HR and Employee roles sit outside the transaction columns above:

A few things in this table surprise people, so they're worth calling out:

• Customers & Suppliers is open to everyone. The contact directory (in the Directory menu, alongside Products & Services) is shared master data used by sales, purchases, collections and compliance, so every member of the organization can view and maintain it. It has no access level to set on the Team & Access page.
• Administrators don't manage the books' configuration. Periods, chart of accounts, taxes, and currency rates are managed by the Accountant role only — the Administrator sees them read-only. This is deliberate segregation of duties between running the company and keeping the books. The organization owner is held to the same line: the owner's built-in access covers everything except these accounting-configuration pages and reversal requests. An owner who keeps the books themselves adds the Accountant role to their own membership under Team & Access, which makes that responsibility visible in the members list.
• Staff can see the chart of accounts (read-only) because preparers need to pick accounts while drafting, but they can't see periods, taxes, or FX settings at all.
• Revealing a full bank account number is never included in any access level — only the Administrator role (or an explicit per-person grant) can do it. Everyone else sees a masked number.
• Changing an employee's sign-in email belongs to HR and the Accountant alone. Not the Administrator, and not even the owner's built-in grant — the employee's login identity is an HR responsibility, the action always demands an authenticator code, and both the old and new addresses are notified.
• Employee-only sign-ins don't use a team seat. A person holding only the Employee role doesn't count against your plan's user limit, and employees are unlimited on every plan.

The organization owner

The person who created the organization is its owner and implicitly holds every oversight permission, regardless of what roles they've been given — team, settings, billing, every transaction module, every report. Two things are deliberately not part of that built-in grant: managing accounting configuration (periods, chart of accounts, taxes, currency rates) and requesting reversals of posted records. Both are maker/bookkeeper actions; the owner gets them only by holding the Accountant (or Staff) role explicitly, which the owner can assign to themselves. This applies only to the owner: another member granted the Administrator role gets exactly the Administrator access above, nothing more. The owner is also not exempt from the three-person rule (you can't review or approve your own work, and whoever reviewed a record can't also approve it) — see Approval Workflow.

Three different people for every transaction

Every financial transaction goes Create → Review → Approve → Post, and the maker, the reviewer and the approver must be three different people. Roles decide what kind of step you may take; this rule decides which records you may take it on. Holding several roles at once (say, sales approval and payment approval, or Accountant plus Approver) never lets one person do two of the steps on the same record, and the owner and administrators are held to it too. A team therefore needs at least three active members before anything can be approved and posted.

Per-person overrides

On top of roles, an administrator can grant or remove individual permissions for a specific person on the Team & Access page — either as a per-page access level (the same scale above) or as individual permission grants. Effective access = everything their roles grant, plus individual grants, minus individual denials. Note that whoever is granting access can only hand out permissions they themselves hold, and that changing someone's roles wipes their individual overrides — re-apply them after a role change.

Setting up test accounts

To exercise every part of the system you need at least three people (nothing can post until a creator, a different reviewer and a third person as approver have each done their step), and a realistic set is five:

1. Owner / Administrator — the account that registered the organization. Sets up the company, invites the team, configures settings and thresholds.
2. Accountant — configures the chart of accounts, periods, taxes, and FX; also useful as a second full-access transaction user.
3. Staff — prepares and submits transactions (the "maker").
4. Reviewer — reviews what Staff submitted (the first checker).
5. Approver — approves what the Reviewer passed on (the final checker; must be a different person from the reviewer).

Add a Viewer if you want to cover read-only behavior separately. (The Accountant or Administrator can stand in as reviewer or approver, as long as no one does two steps on the same record.)