Choose a nonprofit CRM by separating donor administration, beneficiary information and communication permissions before importing records. Define who needs each field for a specific task, then test those boundaries with fictional contacts and ordinary user accounts. A donation record should support the work it belongs to without exposing unrelated programme information to every fundraiser or volunteer.
Start with the relationships your organisation actually maintains. Someone may donate, volunteer and participate in a programme, but those activities need not make every detail relevant to every staff member. Write the purpose of the proposed record before deciding how much information to collect. The practical question is which person may do what with which information.
Which records belong together, and which details need separation?
A shared contact identity can help colleagues recognise the same person. It should not become a reason to combine unrestricted access to donation history and confidential programme notes. Identify the fields needed for fundraising, programme administration and communication choices separately. Treat the resulting map as a requirement to demonstrate, rather than assuming a product label answers it.
CiviCRM provides a documented example of how these boundaries can be configured. Its manual distinguishes permissions defined in the surrounding content management system from CiviCRM access control lists. CMS permissions can control whole areas and record operations; native ACLs provide finer-grained control over selected contacts and data. CiviCRM permissions and access control.
This example is useful because it forces a specific conversation about records, fields and actions. It does not establish that a particular installation already meets your organisation’s consent requirements. Keep the wider platform comparison in the CRM selection guide, and use this article for the nonprofit information boundary.
How should you test access rather than merely assign roles?
CiviCRM ACLs can target contact groups, profiles, sets of custom fields and events. That gives the evaluator concrete objects to inspect. For example, a regional fundraising team might need its own donor contacts, while another team needs a different set of programme fields. The documented model supports asking for those boundaries explicitly. CiviCRM access control.
Check broad permissions before testing a narrow ACL. The manual warns that custom-field ACLs do not function when the broad access-all-custom-data permission is assigned. A configuration can therefore look carefully divided while another permission defeats the intended separation. Test using the actual proposed roles, not an administrator session. CiviCRM permissions.
Build a simple access matrix before the demonstration. These are proposed business requirements, not default CiviCRM permissions.
| Role in the fictional organisation | Intended work | Boundary to demonstrate |
|---|---|---|
| Fundraising administrator | Record and correct donor contributions | No access to restricted beneficiary notes |
| Programme coordinator | Maintain authorised programme information | No routine contribution-editing access |
| Volunteer coordinator | Arrange the agreed volunteer activity | Only the contact details needed for that activity |
| System administrator | Maintain configuration and access | Administrative access is recognised separately from ordinary work |
For every row, test both an allowed task and an attempt to reach information outside the role. Record the account, role configuration, expected result and observed result. If the business cannot agree whether a field should be visible, leave that requirement unresolved instead of letting the demonstrator choose silently.
What does a contribution record actually establish?
CiviCRM’s manual-entry guide explains how an organisation records offline contributions against contacts. If a donor is not already in the database, the contact record is created before the contribution is entered. The contribution form records details including Financial Type, Amount, Received Date and Status. Manual entry of contributions.
Use those documented fields to rehearse donation administration. Check that the contribution is attached to the intended fictional contact and that its date and status reflect the evidence supplied for the exercise. Do not let a correctly saved financial record stand in for a separately agreed communication choice.
Access to contribution data also needs deliberate configuration. CiviCRM documents optional access control by Financial Type for Drupal, Backdrop and WordPress, with Joomla excluded from that feature in the cited guide. If that distinction matters, identify the actual CMS and demonstrate the configured result. A generic product demonstration should not conceal the platform dependency. Financial Type permissions.
Original boundary rehearsal: one person, three relationships
Consider a fictional community organisation. One contact has made an offline donation, offered to volunteer and asked about a support programme. The exercise uses invented information in a test copy; no real beneficiary details are needed.
First, the fundraising administrator records the contribution against the fictional contact. The programme coordinator adds only the information approved for the programme exercise. The volunteer coordinator records the agreed activity and the contact route needed to arrange it. Keep any communication-choice requirement explicit in the brief: what was agreed, for which purpose and who may change the instruction.
Then run three boundary checks. Ask the fundraising account to find the donation without opening restricted programme notes. Ask the programme account to perform its authorised task without changing the contribution. Ask the volunteer account to locate its contact route without gaining broad access merely because the person is also a donor.
Introduce a fourth situation: the person changes the communication instruction for volunteering. The business reviewer should identify which activity that change affects and what evidence staff need to retain. Do not assume it changes every relationship or that one preference field implements the whole requirement. The point is to test a defined boundary, not to invent a consent policy during configuration.
Capture a discrepancy card whenever the observed result differs from the matrix. Name the exposed or inaccessible information, the role used, the configuration version and the person who must decide the correction. Repeat the affected test after the proposed change.
How should batch entry and imports preserve evidence?
CiviCRM batch entry can compare the count and total of recorded payments with the batch definition. Its documentation also allows a user to override a mismatch and process the batch. Consequently, a closed batch is not by itself evidence that no discrepancy occurred. The evaluator should inspect how an authorised person records the reason for accepting or correcting a mismatch. Contribution batch entry.
Use fictional contribution references for the exercise rather than publishing real donation amounts. Compare the source list with the entered contact, date and status. Ask who may change the batch definition and which record will explain that change later.
For imports, the same guide says contributors must already exist as contacts before contributions are imported. Plan contact matching before bulk contribution entry. A name that looks familiar is not enough evidence that an existing relationship record belongs to the person on the source list. Agree how ambiguous matches will be held for review. Contribution imports.
Finish with the access matrix, the fictional rehearsal results and the unresolved communication requirements. Those records explain what the proposed CRM configuration must demonstrate before real data is introduced. For a broader systems brief, see business systems. Bring the boundary matrix when you get started.
By Spout Team. AI-assisted drafting by Codex using the linked primary product documentation; independent editorial review remains pending.