Roles and permissions
Every person on your team holds one of five roles — Owner, Admin, Finance, Member or Viewer — and each role starts with its own default set of what it can see and do, which your organisation’s Owner can change.
Why it works this way
Section titled “Why it works this way”Behind the five role names is a permission matrix: modules (Campaigns, Donations, Donors, Receipts, Financial Reports, Website, and more) crossed with four actions (view, create, update, delete). A role is a starting preset of which cells are switched on. That’s why “what can Finance do” has no one fixed answer forever — an Owner can grant or remove a module for a role in Account access, and everyone holding that role changes at once.
The terms
Section titled “The terms”Owner — full access to everything, always. The Owner role can’t be edited down.
Admin — day-to-day operational access: campaigns, donations, donors, website and receipts, plus organisation settings. Admin does not get Financial Reports by default, so can’t run finance exports until an Owner grants it.
Finance — access built around money: donations, receipts, financial reports and donor tiers, plus organisation settings. Can view campaigns but not create them.
Member — day-to-day giving and donor work: records and updates donations, manages donors, updates (but doesn’t create) campaigns.
Viewer — read-only across campaigns, donations, donors, financial reports and receipts. Can’t be added through Invite Member today — assigned automatically for organisations connected to a JomCARE hub.
Permission matrix — the module × action grid behind every role, editable by an Owner in Account access → Role Permissions. A role’s actual access is whatever the matrix currently says, not what its name implies.
What this means in practice
Section titled “What this means in practice”The table below shows each role’s default — before any Owner customisation:
| Action | Owner | Admin | Finance | Member | Viewer |
|---|---|---|---|---|---|
| Create a campaign | Yes | Yes | No | No | No |
| Publish a campaign | Yes | Yes | No | Yes | No |
| Record a donation | Yes | Yes | No | Yes | No |
| Void a donation | Yes | Can only start a request — always needs approval | Yes | No | No |
| Re-send a receipt | Yes | Yes | Yes | Yes | No |
| Run exports | Yes | No | Yes | No | View only |
| Connect a payment gateway | Yes | Yes | Yes | No | No |
| Invite colleagues | Yes | Yes | No | No | No |
| Edit the website | Yes | Yes | No | No | No |
Two things here are easy to get wrong: an Admin who tries to void a donation always creates an approval request rather than voiding directly — see Set up approvals — and Admin cannot run a finance export by default, despite doing almost everything else.
Do
- Give a new volunteer Member if they’ll record donations and manage donors day to day, and Viewer access (via a JomCARE hub) if they only need to look things up.
Don’t
- Reach for Admin as your default “give them more access” move. Admin can invite other colleagues, connect a payment gateway and edit your public website — check the table above before handing that out to someone who only needs to run reports or record donations.
Worked example
Section titled “Worked example”A volunteer coordinator needs to log offline donations and update donor details, but shouldn’t touch your payment gateway, invite anyone, or edit the website. Member matches that by default — no customisation needed. If they also need monthly finance exports, an Owner can grant Financial Reports to Member in Account access, rather than promoting them to Admin — which would also hand them the website and the invite button.
Related
Section titled “Related”Screenshots use sample data. Every screen on this page is captured against a demo organisation seeded with generated donors, amounts, receipt numbers and campaigns. Any resemblance to a real person or organisation is coincidental.

