Why permissions exist
An organization’s data — donor records, receipts, templates, billing — is shared by everyone with access to it. Roles and permissions let you control who can do what without giving every teammate the same level of access. A volunteer entering donations doesn’t need to touch billing; an auditor reviewing receipts doesn’t need to send them. Tax Receipt Generator models this with five roles, each mapped to a fixed set of thirteen granular permissions, plus a Custom role for cases the presets don’t fit.
The five roles
| Role | View receipts and analytics | Create and edit receipts, manage integrations | Everything else: void receipts, manage templates, manage the team, update the organization, manage billing, export the organization’s data |
|---|---|---|---|
| Owner | Yes | Yes | Yes |
| Admin | Yes | Yes | Yes |
| Member | Yes | Yes | No |
| Viewer | Yes | No | No |
| Custom | Configurable | Configurable | Configurable |
The thirteen permissions fall into three groups, because no role splits them any finer than this. Owner and Admin hold all thirteen; the difference between those two is not a permission at all, and is described below. A Custom member starts with all thirteen off and is granted them individually.
The Export Data permission governs the organization export (Settings, then the organization, then Data export): an Excel workbook of the organization’s receipts, batches, templates and team plus every stored receipt PDF. Owners always hold it; admins hold it by default; members and viewers do not unless granted individually. A personal data export (Settings, then Data & Privacy) is available to everyone and contains only that person’s own account data.
- Owner — every permission is granted, plus protections no other role has: the owner can’t be removed or demoted by anyone else, and only the owner can transfer ownership or delete the organization.
- Admin — holds the same thirteen permissions as Owner by default. The difference from Owner is enforced separately from the permission system: an Admin can’t remove or demote the Owner, can’t transfer ownership, can’t delete the organization, and can’t promote another member to Admin (only the Owner can).
- Member — day-to-day work: view receipts and analytics, create and edit receipts, and manage integrations. Can’t void receipts, manage templates, manage the team, touch billing, or export the organization’s data.
- Viewer — read-only. Can view receipts and analytics; every other permission is off. Useful for auditors or oversight-only stakeholders.
- Custom — starts with all thirteen permissions off. An Owner or Admin turns on exactly the ones this member needs, one at a time, instead of relying on a preset. Use it when someone needs, say, template access without receipt-voiding rights.
Permissions are enforced on the server
Every sensitive action — generating or voiding a receipt, editing a template, inviting a member, changing billing — is checked against the member’s role and permissions on the backend before it runs, not just hidden in the interface. If a button is missing or disabled because a role lacks a permission, that’s a convenience, not the actual protection: the underlying API call is rejected regardless of what the browser shows. This matters because it means permissions can’t be bypassed by calling the API directly or manipulating the page — the server is the single source of truth, and the interface simply reflects it.
Changing a member’s role
From Organization Settings > Team Members, open the member’s detail page and click Edit Member to change their role or, for Custom, toggle individual permissions. Only Owners and Admins can change roles, with a few guardrails: nobody can change their own role, the Owner’s role can only be changed via ownership transfer (not a regular role edit), and an Admin can’t promote another member to Admin — only the Owner can do that. See Team Members for the full walkthrough, including inviting members and managing access across multiple organizations.
How roles interact with approval rules
Compliance approvals (configured per run, not per organization) name specific people as approvers for the Import Data, Generate PDFs, and Send Emails steps — and that list isn’t restricted by role. Any active team member can be added as an approver, whether they’re an Owner, Admin, Member, or Viewer. Role and permissions control what a member can do day to day in the app; being named an approver is a separate, per-run assignment layered on top. See Approval Settings for how to configure approvers and requirements.