A part-time secretary logs in Monday morning to print the Sunday bulletin. A deacon logs in Tuesday night to check who signed up for the men’s breakfast. A pastor logs in Wednesday to add a note about a hospital visit. If all three are using the same login, all three can see all three things — the bulletin, the sign-up sheet, and the note about the hospital visit.
That is not a bug report. It is how one-login church software works, and it is worth saying plainly instead of discovering it the hard way. A congregation of 150 usually has more than one person who needs to get into the system, and small churches rarely have the budget or the appetite to manage separate accounts with separate permissions. So the tradeoff is real: convenience and cost on one side, and the fact that pastoral notes sit behind the same door as everything else on the other.
The tradeoff nobody puts in the sales deck
Most software marketed to churches this size is built around one shared login, not because it is ideal but because it is what a bivocational pastor and a volunteer treasurer can actually manage. Staff roles and permission levels take engineering time to build and administrative time to maintain — someone has to decide who gets which role, and someone has to remember to update it when a volunteer’s job changes. A church running on a handful of people juggling this in the evenings does not have that administrative time to spend.
The honest version of that tradeoff is this: a shared login is simpler to hand out and cheaper to run, and it means anyone holding the password can open anything in the system, including a case note about a member’s marriage or a family’s finances. Software that claims otherwise, at this price point and this size of team, is usually claiming more than it can deliver.
What one login actually means in practice
It helps to walk through it concretely. Say a church has a password shared between the pastor, the office administrator, and two ministry leaders who need to check the calendar and the serving schedule. Once that password exists on four phones and two office computers, the pastoral care module is not four doors deep — it is one click from the dashboard those same four people land on every time they sign in.
Nobody has to go looking. A ministry leader checking Sunday’s volunteer count might see “3 open cases” on the dashboard without meaning to, simply because the same login shows them everything the system tracks. Whether they click through depends on their character, not on the software’s design. That is the part worth sitting with: the protection here is human, not technical.
Why pastoral notes are different from a giving record
A shared login exposes every record type to the same risk in theory, but not every record type carries the same weight. If a volunteer sees that a family gave a certain amount last month, that is awkward. If a volunteer sees a note that a member disclosed something in confidence during a hospital visit, that is a different order of harm — to trust, to the person’s willingness to ever confide in staff again, and possibly to someone’s safety if the note involves abuse, addiction, or a family crisis.
This is why pastoral care records deserve a harder look than attendance numbers or group rosters. The stakes of a leak are not symmetrical across a church database, even though the login that protects them is.
Who actually holds the password, and how that spreads
Most churches do not lose control of a shared login all at once. It happens gradually: the office administrator shares it with a new volunteer who is helping with data entry for a season. That volunteer writes it on a sticky note or saves it in a phone. Six months later the volunteer has moved on, but the password has not changed, and nobody remembers exactly who still has it.
- Ask, before handing out the password: does this person need to see pastoral notes to do the job in front of them, or only the calendar, the directory, or the giving report?
- Change the password when a volunteer’s role ends, the same way you would change the lock on a door when someone moves out.
- Keep a short, current list of who has the password, even if it lives in a notebook rather than a system.
None of this requires new software. It requires treating the password the way you would treat a key to the file cabinet where you used to keep this same information on paper.
What you can do about it without buying different software
If the honest constraint is one login, the honest response is to work with that constraint rather than pretend it is not there. Some churches keep the most sensitive cases — the ones involving abuse disclosures, active legal matters, or anything a mandatory reporter would need to escalate — out of any shared system entirely, in a conversation with a denominational office or an attorney instead of a text field anyone can open. Everything else — a note that someone is recovering from surgery, a reminder to follow up after a difficult season, a record that a deacon visited — can live in the case history because it is discreet, not classified.
In SundayBridge, case notes and comments are kept in a pastoral care module separate from the directory a volunteer would browse to find a phone number, which at least means nobody stumbles into a case note while looking up a family’s address. But separate does not mean locked; anyone signed in can still navigate there. Knowing that in advance is what lets a church decide what belongs in the system and what does not.
Deciding what belongs in the case notes at all
A useful test before typing a note: would you be comfortable if the volunteer who checks in nursery workers on Sunday morning read this by accident? If the answer is yes — “visited John in the hospital, doing well” — write it down. It helps the next person who checks on him know what has already happened. If the answer is no, the note probably belongs in a private conversation, a locked file, or nowhere written down at all.
This is not a workaround for a limitation. It is the same judgment call pastors have made for as long as there have been paper files in a locked drawer, and it holds up regardless of what system holds the record.
When a shared login is actually fine
It is worth saying the other side of this plainly: for a great many churches, a shared login among two or three trusted staff and a couple of long-serving volunteers is not a real risk. Trust is not a workaround; in a congregation where the people with access have known each other and the families involved for a decade, the exposure is theoretical more often than it is a real problem. The risk grows with the number of hands holding the password, not with the software itself. A church that hands the login to every small group leader every semester has a very different exposure than one that keeps it with the pastor and one administrator.
What to ask before you build a workaround
Some churches respond to this by inventing their own workaround — a second, unofficial notebook for the notes nobody should see in the system, kept in a locked drawer. That can be a reasonable answer, but it is worth asking a few questions first: who besides the pastor knows the notebook exists, what happens to it if the pastor changes churches, and whether keeping two records of the same relationship — one in software, one on paper — creates its own confusion about which one is current. A workaround that only one person understands is not much of a safeguard.
The plainer path for most churches this size is to decide, as a matter of practice rather than software configuration, who gets the password and what belongs in a note, and to revisit both of those decisions when a volunteer’s role changes. See how this fits into a weekly admin rhythm and how it relates to building a directory your team trusts in the first place. If your records have grown messy enough that nobody is sure who has access to what, cleaning up the database is often the first honest step before this conversation can happen at all.