Why do roles and permissions matter?
An NGO system holds budgets, staff files, partner details and sometimes data about people in crisis. If everyone can see everything, one lost password or one careless click can cause real harm. If access is too tight, staff work around the system with spreadsheets and email, and the records stop being complete.
Roles solve both problems. A role is a named bundle of permissions. Instead of deciding access for each person one by one, you decide it once for each job, then assign people to jobs.
What is the difference between a role and a permission?
A permission is one thing a person may do, such as view a budget, edit a payment request or approve a purchase. A role is a set of permissions that fit a job, such as “Finance officer” or “Field officer”.
Three kinds of permission matter most:
- Read: the person can see the record.
- Change: the person can create or edit it.
- Approve: the person can sign it off, so it becomes official.
Treat these separately. A program manager may need to read the budget but not change it. A finance officer may change the budget but not approve their own entries.
How do you design the roles?
Follow these steps.
- List the jobs. Write one line for each job family in your organization, not each person.
- List the records each job touches. Think of budgets, payments, staff files, program data, beneficiary data, documents.
- Mark read, change or approve for each pair of job and record type.
- Merge jobs with the same marks into one role. Fewer roles are easier to review.
- Name roles by function, not by seniority or by a person’s name.
- Test with real people. Ask one person from each role to try their daily tasks and tell you what is missing or too much.
A simple starting grid looks like this.
| Record type | Finance | Programs | Field | Leadership |
|---|---|---|---|---|
| Budget | Change | Read | None | Read and approve |
| Payments | Change | Request | None | Approve |
| Program data | Read | Change | Change | Read |
| Staff files | Limited | None | None | Limited |
The grid is an example. Your own rules and donor requirements decide the real values.
Write the grid on one page and share it with each team lead before you build anything. Leads know their work, and they will spot a missing permission within minutes. Keep the page; it becomes your access policy and your evidence when a donor or auditor asks how you control access.
Which duties should never sit with one person?
Separation of duties means no single person controls a whole process from start to finish. The common pairs to keep apart are:
- raising a payment request and approving it,
- approving a purchase and recording that goods arrived,
- creating a vendor and paying that vendor,
- managing user accounts and approving payments.
Be careful when you give one person more than one role. Two roles that look harmless on their own can add up to a gap. Before you save a combined assignment, read the full list of permissions the person will hold.
How do you handle joiners, movers and leavers?
Most access problems appear when people change jobs, not when they join.
- Joiner: assign the role that matches the job description. Do not copy another person’s access.
- Mover: when someone changes job, remove the old role first, then add the new one. People who collect roles over the years end up with far too much access.
- Leaver: remove access on the last working day. If the person’s records must stay, keep the records and remove only the account’s access.
- Temporary access: set an end date when you grant it.
Assign one person to own this process, usually in operations or HR, and have HR tell them about every change. Also keep at least two people who can manage accounts, so access work does not stop when one is away. Do not let account managers approve payments with the same account.
How often should you review roles?
Review twice a year for small teams, and always after a restructure or an audit finding. A review has three checks:
- Does each role still match a real job?
- Does each person hold only the roles they need today?
- Is anyone holding access they have not used for months?
Keep the result: the date, who checked, and what changed. Our article on what an activity log should record explains how to keep the evidence for such changes.
Where EMPOBase fits
EMPOBase has preset roles such as Owner, Organization Admin, Country Director, Programme Manager, Finance & Admin Officer, MEAL Officer and Field Officer. You can rename editable roles, create custom roles and give one user more than one compatible role. Permissions cover module access and actions such as reading, editing, approval, invitations and exports. Some combinations are blocked to protect separation of duties. Review the permissions of each role before you assign it. See the documentation on roles and the security page for the details.