Roles & permissions reference
The complete reference of every WAQAF role, grouped by module, and exactly what each one can see and do.
This is the authoritative list of every role WAQAF offers and what each one can and can't do. Reach for it when you're deciding which role to give a colleague, working out why a button is missing, or simply want to understand how access is organised. It's the detailed companion to the friendlier Why can't I see a button?, which explains the everyday experience; this page is the full table of record.
Who can do this. Anyone may read this reference. Only an Owner or Org Admin can actually grant or change a member's roles — see Assigning roles. Everything below is exact to how WAQAF enforces access on the server, so you can rely on it when planning who gets what.
How roles work in WAQAF
A few principles run through every role. Understanding these first makes the tables below much easier to read.
- Roles are per organisation. You hold roles inside a particular organisation, and they can differ from one organisation to the next. You might be a Finance Manager in one charity and a read-only viewer in another.
- Roles are multi-assignable, and they combine. One person can hold several roles at once — for example Finance Manager and Auditor. When you do, your permissions are the sum of all your roles: you can do anything that any one of them allows. Roles never cancel each other out.
- The server is the real gate. WAQAF checks every action against your roles on the server. The dashboard simply hides what your roles can't reach, which is why a button can be "missing" — that's the system working, not a fault.
- Seeing and changing are separate. Almost every module splits reading from creating, updating, approving and exporting. A role can let you open and even export a list while giving you no button to change a single record (the Auditor is the clearest example).
The action words you'll see
Each module grants a role some combination of these capabilities. The same verbs recur across modules, so it's worth learning them once:
| Action | What it lets you do |
|---|---|
| Read | Open and view the records in that module. |
| Create | Add new records (record income, add a donor, create a fund, and so on). |
| Update | Edit existing records. |
| Approve | Sign off an item that needs approval — chiefly the expense approval chain. |
| Export | Download the data (for example to a spreadsheet). |
| Read balances | See the actual money figures — fund and category balances. This is restricted; see the note below. |
| Read sensitive | See sensitive financial detail beyond the everyday list. |
| Publish | Make website or project content live (distinct from editing a draft). |
| Read PII | See personal data — a donor's or beneficiary's contact details. |
Balances are deliberately restricted. The ability to see actual money figures (read balances) is held only by senior finance and executive roles — Finance Manager, CEO, and Auditor (through read sensitive). An Accountant can record and edit entries and will be told whether there's enough in a fund to cover something, but does not see the figure itself. This is by design: it lets day-to-day bookkeeping happen without exposing the charity's balances to everyone who touches the books.
The two governance roles: Owner & Admin
Above the module roles sit two governance roles. These are the only roles that can manage the organisation itself — its members, invitations, settings, and billing — and they hold every module permission on top of that. Think of them as "runs the organisation", whereas the module roles below are "does a job within it".
| Role | What it can do |
|---|---|
| Owner | The highest level of access. Same management powers as an Admin, plus protected ownership: the Owner role can't be changed away in the dashboard, and every organisation must keep at least one Owner. |
| Org Admin | Manages the organisation's settings, members, invitations, and billing — the same day-to-day governance powers as the Owner. Also holds every module permission. |
| Member | The baseline role everyone has. Can use the organisation workspace and view the website, but cannot reach organisation settings, manage members, or see billing. Module access comes from the additional roles you're given. |
Because Owner and Admin already include every module permission, you don't normally stack a module role on top of them. You give module roles (Accountant, Site Editor, and so on) to the Members who do those specific jobs.
Finance roles
The finance roles govern the accounting books — income, expenses, funds, and approvals. This is where the read balances and read sensitive restrictions matter most.
| Role | Can do |
|---|---|
| Finance Manager | Full accounting access: read, create, edit, approve, export, see balances, and see sensitive detail. Also manages funds (create, edit, delete), handles donation refunds, and sees the donor list. The senior finance role. |
| Accountant | Reads, creates, edits, and exports accounting entries, and views funds. Cannot approve, and cannot see balance figures — only whether a fund has enough to cover something. |
| Auditor | Read-only across the books, including sensitive detail, with export. Can review everything — even export it — but has no button to change any record. The ideal role for an external or internal reviewer. |
| CEO | The executive role. Approves expenses (the final step of the chain), sees balances and sensitive finance detail, and exports. Also gets cross-module read access — donors, funds, projects, campaigns and beneficiaries — for oversight, but does not edit the books day to day. |
The expense approval chain. Every expense runs a fixed chain of sign-offs — Accountant → Finance Manager → CEO — regardless of the amount. The role grants the ability to approve; the chain decides whose turn it is right now. When the CEO is unavailable, a Finance Manager may approve the CEO's step on their behalf so the chain doesn't stall. See Why can't I see a button? for why an approver sometimes sees the button greyed out.
Money is never deleted. WAQAF keeps an immutable ledger. A mistaken entry is never erased — it's corrected with a reversing entry that cancels it out, leaving both on the record. So "who can approve and reverse" (Finance Manager, CEO) is a far more consequential grant than "who can read" — choose finance roles carefully.
Donor roles
The donor roles govern the CRM: the people and organisations who give. The key split here is personal data (a donor's contact details) — some roles see it, some don't.
| Role | Can do |
|---|---|
| Donor Manager | Full access to donors and donations, including personal data: read, create, edit, export, and delete donors; read and export donations. |
| Donor Editor | Reads, creates, and edits donors including personal data, and views donations. Cannot delete donors or export. |
| Donor Viewer | Views donors and donations, but without personal data — names and totals without the private contact details. |
A Finance Manager also sees the donor list and can handle refunds, because donations are part of the books — but a donor's personal data still requires a donor role that grants it. The two modules overlap deliberately at the edges.
Website roles
The website roles govern your public site — its pages, theme, SEO, domains, the payment connection that lets the site take donations, and the WhatsApp messaging setup. The split here is between editing a draft and publishing it live, plus control of the more sensitive connections.
| Role | Can do |
|---|---|
| Site Manager | Full control of the website: read, create, edit, publish, and delete pages; manage the theme, SEO, domains, the payment connection, and messaging. The senior website role. |
| Site Editor | Edits website content, theme, and SEO, and creates pages — but cannot publish, and cannot manage domains or the payment connection. Sees messaging read-only. |
| Site Viewer | Views the website configuration, theme, and SEO. Read-only. |
Publishing, domains, and the payment connection are kept to the Site Manager on purpose: the payment connection is what lets your live site accept real donations, so changing it is a senior action, not an everyday edit.
Project roles
The project roles govern projects, campaigns, and beneficiaries. They add one extra idea: some roles see all projects, while a coordinator sees only the ones assigned to them. As with donors, personal data (a beneficiary's details) is gated.
| Role | Can do |
|---|---|
| Project Manager | Full control of all projects: create, edit, publish, and delete projects; full control of campaigns; and full access to beneficiaries including personal data. Also reads donations. |
| Project Coordinator | Works on assigned projects only — reads and updates the projects given to them, views campaigns, and reads, creates, and edits beneficiaries (without delete). |
| Project Viewer | Views all projects and campaigns, and beneficiaries without personal data. Read-only. |
Putting roles together
Because roles combine, you build a person's access by stacking the roles that match the hats they wear. A few common patterns:
One job, one role
Most people need a single role: an Accountant who keeps the books, a Site Editor who maintains the website, a Donor Viewer who looks up supporters. Give the one role that fits.
Several jobs, several roles
Someone who keeps the books and reviews them can hold Finance Manager + Auditor. Someone who runs both the website and the donor list can hold Site Manager + Donor Manager. Their permissions add up — they get everything either role allows.
Runs the organisation
The people who manage members, settings, and billing get Owner or Org Admin, which already include every module permission — so they rarely need a module role on top.
If a colleague is missing an action, the fix is usually small: an Owner or Org Admin adds the one role that grants it, rather than swapping their whole assignment. See Assigning roles for the exact steps.
See also
Why can't I see a button?
The friendly explanation of why a button or section is hidden from you.
Assigning & changing roles
How an Owner or Org Admin adds or changes a member's roles.
Inviting members
Bring new people into your organisation and set their role.
Login & security policy
Organisation-wide sign-in rules that apply to every member.