TLDR
Permission systems that need a consultant to configure are permission systems the average nonprofit never locks down correctly. GrantPipe uses three roles — Admin, Editor, Viewer — that cover every legitimate access pattern for nonprofit operations staff without custom permission sets or support tickets.
Role-based permissions control who on your team can do what in GrantPipe. Three roles cover every legitimate access pattern in nonprofit operations: Admin for people who configure and maintain the system, Editor for people who do the day-to-day data work, and Viewer for people who need to see the data without touching it.
TL;DR
- Three roles: Admin, Editor, Viewer
- Admin assigns roles — no support ticket, no consultant, no setup project
- Editor: create/edit/import but cannot delete or configure org settings
- Viewer: full read access to all records and reports
- Per-entity role assignment in multi-entity setups
- Audit trail shows every user action; deactivated users lose access immediately
What this feature does
Role assignment is a two-field action: pick a user, pick a role. The role takes effect immediately. No approval queue, no configuration form, no support ticket. The same is true for deprovisioning: deactivate a user and they cannot log in. Their data, their audit history, and their record assignments remain.
The three-role model is designed to match the actual access requirements of nonprofit operations staff. Development staff need Editor access to create and update donor and grant records. Finance staff who review data for reconciliation need Viewer access. Board members need Viewer access for dashboards. The executive director and the person responsible for system configuration need Admin access.
The audit trail enforces accountability at every role level. Every record create, edit, and delete is logged with the user and timestamp. Admins can filter the audit trail by user to review what a specific staff member has done. Role enforcement is not just a control — it is verifiable after the fact.
Who it’s for
Executive directors who want to give board members read access to dashboards without worrying about accidental edits. Operations staff responsible for onboarding new team members and offboarding departing staff. Finance staff who need visibility into donor and grant data for reconciliation without needing edit access.
The consultant-configuration problem
Some CRM platforms use permission models with dozens of granular settings — object permissions, field-level security, profile configurations, permission sets, sharing rules. The platforms are flexible, but configuring them correctly requires expertise that most nonprofit operations staff do not have. The result: organizations leave the default permissions in place, which typically give every user more access than they should have, because locking it down correctly requires a consultant engagement.
GrantPipe’s three-role model trades granularity for clarity. If your access requirements fit within Admin, Editor, and Viewer — and the requirements of almost every mid-sized nonprofit do — configuration takes minutes and requires no external expertise.
Workflow example
Onboarding a new grants manager:
- Admin navigates to Settings > Team
- Clicks “Invite user,” enters the new grants manager’s email
- Selects the Editor role
- The invitation email goes out; the new staff member creates a password and logs in
- They have Editor access to all grant records, can update deadlines, upload documents, and edit grant details
- They cannot delete records or change org settings
When they leave:
- Admin navigates to Settings > Team, finds the departing staff member
- Clicks “Deactivate” — they lose access immediately
- Their grant assignments are bulk-reassigned to the replacement via the reassignment tool
- Their audit trail history remains, documenting their actions during their tenure
Integration with the rest of GrantPipe
Roles interact with multi-entity consolidation (per-entity role assignments), the audit trail (role-based visibility into audit logs), and custom field administration (custom field creation and deletion is Admin-only). The Viewer role works well with board dashboards — configure a dashboard, give board members Viewer access, and they can view current data without the ability to change anything.
What it replaces
- The informal access model where everyone has Admin because no one set up roles at implementation
- The consulting engagement to configure field-level security and sharing rules in a more complex platform
- The manual process of changing email passwords when staff turn over because there was no formal user management
- The spreadsheet tracking who has access to which system because the platform had no audit trail
Start a free trial
Free resource
Get the Nonprofit Grant Compliance Checklist
A practical checklist for post-award grant compliance: restricted funds, reporting cadence, audit prep, and common failure points. Delivered by email.
Source: Nonprofit Technology Network (NTEN) 2024 Security Survey
Q&A
What access level is appropriate for a board member?
Viewer. Board members need read access to financial dashboards, donor retention reports, and grant status summaries. They have no operational need to create or edit records. The Viewer role gives them full read access without the ability to accidentally modify data they are reviewing.
Q&A
What access level is appropriate for a program staff member who submits grant reports?
Editor. Program staff who upload report documents, update grant milestones, and complete reporting deadlines need create and edit permissions on the grant record. They do not need Admin access to org settings or custom field definitions.
Q&A
How should a finance staff member be configured if they need to see donor data but not edit it?
Viewer. Finance staff who need donor giving totals and fund allocation data for reconciliation do not need to edit donor records. Viewer access gives them read access to all records, reports, and exports without the risk of accidental edits.
Frequently asked