Choose a church CRM by testing who can see a person’s information, who owns follow-up and how access ends when a volunteer changes role. A shared congregation database should not become a shared pastoral notebook. Start with a permissions-and-follow-up exercise before importing member records or connecting communication channels.
The useful distinction is between knowing that someone needs a welcome call and knowing everything the church has recorded about that person. Different responsibilities may justify different access. Write those responsibilities down before comparing screens. The guidance below uses the People application’s documentation as a concrete example; it does not establish Zambian legal compliance, local payment availability or the suitability of every subscription.
What belongs in a church relationship record?
Separate member contact information, participation records, volunteer responsibilities and confidential pastoral material in the requirements brief. Do not assume one broad contact record is the right home for each. Ask the people responsible for the information to explain why a field is needed, who should maintain it and what decision it supports. Leave unnecessary sensitive information out of the demonstration.
The documented People application is intended for staff use. Its permissions documentation distinguishes that staff-facing purpose from the congregation directory. This matters when a demonstration appears to offer “access for everyone”: staff administration and member-to-member visibility are different choices. Ask to see both perspectives using fictional accounts rather than treating the administrator’s screen as evidence of what a member sees.
A collaborator can receive access to a specific resource. In the documented example, that resource might be a list, workflow or note category. This gives the evaluation a more precise question than whether the software has permissions. Ask which resource is being shared, which actions are available there and whether sharing it exposes any other part of the database.
How can volunteers follow up without seeing everything?
A workflow is initially accessible only to its creator. Workflow access can be assigned to a person or permission level. Those documented controls are useful starting points for a welcome-team example, but the relevant evidence is the volunteer’s actual view in the proposed configuration.
Workflows-only access restricts the user to the Workflows page. Workflows-only collaborators cannot save notes to profiles. This is a meaningful boundary for a person who needs to complete an assigned welcome call without becoming a general database editor. Record the exact permitted activity and any work that still requires a staff member; do not describe restricted access as equivalent to full pastoral administration.
A person without workflow access cannot see its cards. Ask the demonstrator to remove access and check the result through the former collaborator’s account. Test both the workflow list and the individual card route. Keep this in a separate demonstration organisation with fictional information, and record any difference between the expected restriction and the observed behaviour.
Which permissions need a separate conversation?
Only an organisation administrator can delete People profiles. Deletion is therefore a different requirement from correcting a contact detail or completing a follow-up card. Identify the responsible decision-maker and the intended record-retention process before requesting broad administrative access. The software’s available permission does not determine the church’s policy.
Permissions in other products can also allow editing in People. Reviewing one screen alone can therefore give an incomplete picture. Include connected products in the permission inventory and ask the demonstrator to explain any access inherited through them. A volunteer’s modest-looking People role is not enough evidence if another product grants wider editing rights.
Removing People permissions prevents subsequent access. The operational question is who initiates that change when a person moves role, leaves a team or no longer needs the record. Name an owner and a confirmation step. Avoid leaving the task dependent on someone remembering which account was used months earlier.
| Requirement | Demonstration account | Evidence to retain |
|---|---|---|
| Welcome follow-up | Assigned volunteer | Visible cards, permitted updates and inaccessible profile areas |
| Contact correction | Staff editor | Which fields can change and who owns the correction |
| Confidential information | Authorised pastoral role | Resource visibility and the result of a denied-access attempt |
| Access removal | Former collaborator | Workflow and profile access after removal |
| Connected-product access | User with another product role | Any additional editing rights and their origin |
Original welcome-team access worksheet
Use this original worksheet to compare a proposed church CRM against a specific working arrangement. It is a suggested acceptance exercise, not a claim that Spout has tested a church deployment. Use fictional people, fictional contact details and an isolated test organisation. Do not copy a pastoral record into a trial simply to make the demonstration look realistic.
Create the relationship card. Describe one fictional visitor who has requested contact from the welcome team. Write the purpose of the follow-up, the assigned person and the information needed to make that contact. Add a separate fictional sensitive note that the volunteer should not see. The point is to test separation, not the quality of the note’s wording.
Define the accounts. List a staff administrator, a welcome-team collaborator and a user with no assignment. For each, write the expected visible resources and permitted actions before opening the software. This prevents a convenient default from quietly becoming the requirement. Keep the person’s organisational role separate from the name of a software permission.
Walk through the handover. Ask the administrator to assign the follow-up and the volunteer to continue it. Record how the task becomes visible, what can be updated and which next action belongs to staff. Try a reassignment without moving unrelated records into the volunteer’s view. If the handover needs a broader role, capture that as a configuration or scope question.
Test the boundary. Through the volunteer and unassigned accounts, inspect the workflow, the fictional person’s profile and any connected-product route included in the proposal. Record observed behaviour rather than ticking a generic “secure” box. A failed restriction needs an explanation and a repeatable correction before the requirement can be accepted.
Close the access loop. Remove the collaborator’s assignment or permission using the documented process. Check the former access routes again and record the result. Include a separate question about information previously exported or copied: removing application access does not, by itself, demonstrate what happened to an earlier export.
The completed worksheet should identify an information owner, a follow-up owner and an access-removal owner. They may be the same person in a small team, but the responsibilities should remain visible. Compare systems using that record, not the size of a feature list.
For the broader software decision, see business systems and business cybersecurity. To discuss a church’s requirements, get started with the fictional access matrix and the questions the demonstration has not resolved.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.