Role-based access for masjids, explained
Why the imam shouldn't see treasurer reports, and the treasurer shouldn't be able to publish khutbahs. A practical guide.
When a masjid first signs up for MasjidDesk, the founding admin almost always invites the rest of the board with the same role: full admin. It's the path of least resistance, and it works — until it doesn't.
Six months in, someone accidentally publishes a draft khutbah from a phone in their pocket. A volunteer pulls a donor list to invite people to a fundraiser without realizing donor amounts are visible to them. The treasurer gets a notification every time a member updates their address. None of these are catastrophes — but they're friction, and friction is what kills software adoption inside an organization.
Role-based access control (RBAC) is the standard fix. Below is how we explain it to boards we onboard.
Three principles, in plain language
- Least privilege. Each person sees and can do only what their job requires. Not because we don't trust them, but because we want to remove decisions they shouldn't have to make.
- Separation of duties. The person who records donations is not the same person who approves expense reimbursements. Not because they'd defraud you, but because that's the audit posture every nonprofit board should aim for.
- Auditability. Anything sensitive — refunds, role changes, exports — shows up in an audit log with who, what, when, and from where.
| Role | Donations | Members | Events | Finance | Madrasa | Settings |
|---|---|---|---|---|---|---|
Owner | Edit | Edit | Edit | Edit | Edit | Edit |
Treasurer | Edit | View | View | Edit | — | — |
Imam | — | View | Edit | — | View | — |
Madrasa lead | — | View | View | — | Edit | — |
Volunteer | — | — | View | — | — | — |
The roles we ship by default
These roles are a starting point. Most masjids customize them within a week, which is fine — the goal is a sensible default, not a rigid framework.
- Owner. One per organization. Can do everything, including transfer ownership and delete the tenant.
- Treasurer. Edits donations, expenses, and finance. Views members. Cannot publish announcements or change settings.
- Imam. Edits events, prayer-time overrides, and announcements. Views members. Cannot see donation amounts.
- Madrasa lead. Edits the madrasa module — classes, attendance, tuition. Views members.
- Volunteer. Sees only the events and shifts they're assigned to.
What we deliberately don't do
We don't let you build arbitrarily fine-grained roles in the UI. You can't create a role that has "view donations from before July 2024 but only for donors whose last name starts with M." That kind of complexity sounds powerful and is, in practice, a security hazard — because nobody can reason about it later.
If you need true custom roles, the API supports them and we'll help you set them up. For everyone else, the five defaults plus a handful of toggles are enough.
A practical onboarding rule
When you invite a new admin, give them the most restricted role you think might still work, then upgrade if they ask. It's much easier than trying to take permissions back later.