How to Configure Raiser’s Edge Security Roles

A development coordinator should be able to enter a gift without changing a fund record. A gift officer should see the constituents in an assigned portfolio without browsing every donor relationship in the database. Finance should have confidence that reports and reconciliation data are protected from accidental changes. When you configure Raiser’s Edge security roles around these real responsibilities, security becomes an operational control rather than an obstacle to fundraising.

For many nonprofits, access has grown over time: a new employee receives the same permissions as a predecessor, a temporary project requires broader access, or an urgent reporting need leads to an exception that is never revisited. The result is often more access than staff need, unclear accountability, and unnecessary exposure of donor and financial information. A deliberate security structure protects data quality while keeping development, finance, and advancement services moving.

Start With Job Functions, Not Individual Users

The strongest security model begins with a simple question: what work must each person complete in Raiser’s Edge? Do not start by building permissions for individual names. Start with repeatable job functions, then assign people to the appropriate security group or role.

A typical organization may need distinct roles for gift processing, gift officers, development leadership, database administration, reporting, finance review, and occasional or limited users. The exact model depends on team size and workflow. A small nonprofit may combine several functions in one role, while a larger advancement office may need separate permissions for annual giving, major gifts, events, prospect research, and advancement services.

This approach makes onboarding and offboarding more reliable. It also makes access reviews easier because leadership can evaluate whether a role remains appropriate for a position, rather than deciphering a long list of one-off permissions.

In Raiser’s Edge NXT and database view, the labels and available controls can vary by feature and configuration. Your team may work with security groups, user permissions, system roles, or a combination of these. The principle remains the same: establish a role design based on responsibility, then apply the least access necessary for that responsibility.

Configure Raiser’s Edge Security Roles Around Least Privilege

Least privilege means giving each user the minimum level of access needed to perform assigned work. It does not mean making every task difficult. It means distinguishing between viewing, adding, editing, deleting, exporting, and administering data.

Gift processors, for example, may need to add and edit gifts, review constituent records, and run specific batch or exception reports. They rarely need permission to alter global configuration, delete records, or manage user security. A gift officer may need to view assigned prospects, record actions, and maintain proposals, but may not need access to gift batches or organization-wide exports.

Administrative access deserves particular care. Database administrators and designated system owners need broader authority to manage configuration, integrations, global settings, and security. That access should be limited to a small number of trained staff and reviewed regularly. Broad administrative rights are convenient during a busy period, but they create a larger risk surface for accidental changes and unauthorized access.

As you set permissions, separate these decisions:

• Who can view sensitive constituent, gift, and prospect information

• Who can create or edit records, actions, gifts, appeals, funds, and attributes

• Who can delete or globally change information

• Who can run exports, execute imports, manage integrations, or alter system settings

The distinction between edit and delete access is especially valuable. Most users who update records do not need the ability to remove them. Limiting deletion rights helps preserve auditability and reduces the chance that a cleanup effort or duplicate-record correction creates irreversible data loss.

Protect the Data That Carries the Most Risk

Not all Raiser’s Edge data requires the same level of protection. Donor contact information is sensitive, but some fields carry added privacy, financial, or reputational implications. Examples include giving history, pledge balances, wealth ratings, prospect research notes, relationship details, payment information, anonymous gift indicators, and confidential actions.

Identify the data categories your organization considers restricted, then document which roles can view and edit them. This should include fields created locally, not only standard fields. Custom attributes often hold meaningful operational details, such as donor preferences, internal stewardship notes, grant compliance information, or screening results. Because custom fields evolve over time, they are easy to overlook during a security review.

Field-level controls, record restrictions, and query or export permissions should work together where available. Restricting a sensitive field is helpful, but the protection is weakened if a user can export a broad constituent list containing comparable information from another source. Review access from the perspective of what a user can ultimately see, report on, download, or transmit.

Portfolio-based access can be useful for gift officers and regional fundraisers, particularly when an organization manages complex major-gift programs. Yet it requires thoughtful maintenance. If portfolio assignments are incomplete or stale, staff may lose access to the prospects they need or retain access after a reassignment. Build portfolio updates into the advancement operations process, not just into a manager’s informal handoff.

Account for Segregation of Duties

Security roles should support internal controls as well as privacy. In gift processing, one person should not have unrestricted ability to enter, adjust, approve, and reconcile transactions without review. Smaller organizations may not have enough staff to separate every duty, but they can still build compensating controls through approval reports, batch review, reconciliation procedures, and limited permissions.

For example, a staff member may enter gifts and prepare batches, while a supervisor reviews batch totals and exceptions before posting or final approval. Finance may need read-only access to gifts, deposits, and reconciliation reports, rather than full authority to edit fundraising records. Development leadership may review campaign performance and donor activity without requiring the ability to change accounting-related setup.

The right division depends on staffing, transaction volume, and organizational risk. The point is not to impose enterprise-level complexity on every nonprofit. It is to make sure that high-impact changes receive an appropriate level of review.

Build Roles That Support Reporting Without Creating Data Leakage

Reporting is one of the most common reasons access expands beyond its original purpose. A staff member needs a donor list for an event, a leadership report, or a campaign analysis, so export or query permissions are granted broadly. Over time, access to large amounts of constituent data becomes routine.

Instead, define reporting access by role and use case. Development directors may need broad dashboard and report visibility. Event staff may need attendance, registration, and selected constituent contact information. Program staff may need a limited report for stewardship activities without access to full giving history or prospect notes.

Where your processes allow it, centralize high-risk reporting requests through advancement services or database administration. This is particularly useful for exports that include large constituent populations, giving data, or sensitive attributes. Centralization can feel slower at first, but well-defined request procedures and reusable reports usually reduce delays while creating a clearer record of how data is shared.

Be careful with shared credentials and shared exports. A report delivered to a shared drive or inbox can outlive the original purpose and be accessed by people outside the intended role. Security planning should include where reports are stored, how long they are retained, and who is responsible for removing outdated files.

Test Roles in Real Workflows

Permissions that look appropriate on paper can fail in practice. Before assigning a new security role broadly, test it using a non-administrator account or a controlled test user. Ask the user to complete the work they actually perform: enter a gift, review a constituent, add an action, run a report, correct a batch exception, or update a proposal.

Testing should confirm two things. First, authorized users can complete their work without workarounds that undermine security. Second, they cannot access areas beyond their responsibility. Document exceptions and determine whether the role should change or whether the workflow needs a defined approval step.

This testing is particularly important after changes to integrations, forms, online giving processes, data imports, or reporting tools. An integration account may require access that a human user does not, and its permissions should be narrowly scoped, monitored, and documented. Treat integration credentials as operationally critical accounts, not as permanent background settings.

Make Security Review a Recurring Operations Task

Security design is not complete when roles are created. Staff change positions, temporary assignments become permanent, vendors receive access, and new fields or processes introduce new risk. Schedule periodic reviews at least annually, with additional reviews after major staffing changes, audits, system changes, or fundraising process redesigns.

During a review, compare active users against current employment and role assignments. Confirm who has administrative privileges, who can export data, who can delete records, and which accounts are used for integrations. Review inactive or duplicate accounts, former employees, consultants, and shared access patterns. Keep a brief record of the review, decisions made, and follow-up actions.

Training matters as much as configuration. Staff should understand that security is connected to donor trust and data quality, not merely a technical rule. When users know why a permission boundary exists, they are more likely to request access through the right process and less likely to create informal workarounds.

A well-designed Raiser’s Edge security model gives your team room to do meaningful work while protecting the information donors have entrusted to your organization. If your roles have accumulated through years of staff changes and urgent exceptions, a focused security assessment can turn that history into a clearer, more dependable foundation for fundraising operations.