Ask a software salesperson about staff roles and permissions and they will describe a tidy world: the pastor sees everything, the treasurer sees giving, the volunteer coordinator sees the serving schedule, and nobody sees what is not theirs to see. It is a fine picture. Very few churches under 250 people actually live in it.
What most small teams have is one login, a handful of people who know the password, and an unspoken understanding — mostly honored, occasionally not — about who touches what. That is not a failure of discipline. It is the honest shape of a volunteer-run office, and it works fine once you stop pretending the software will enforce boundaries it was never built to enforce.
Why staff roles are rare below 250 people
Role-based permissions exist to solve a problem larger organizations have: dozens of employees, high turnover, and a real need to limit blast radius when someone leaves on bad terms. A church with a bivocational pastor, a part-time secretary, and a rotating cast of volunteers has a different problem. There is no IT department to configure roles, no HR process to revoke access on a Friday afternoon, and often no consensus on who even counts as staff this quarter. Software built for that reality tends to skip roles entirely and give the whole church one account, the same way a family shares one streaming login rather than issuing each member a profile with its own restrictions.
SundayBridge is built this way on purpose: one login per church, no permission levels to configure. It is a smaller promise than “enterprise-grade access control,” and it is the honest one for a team this size.
The real boundary is a habit, not a setting
If the software will not draw the line, your team has to draw it with agreement instead. That sounds fragile compared to a permission checkbox, but in practice it works about as well, because small-church teams already run on trust and spoken understanding for everything else — who counts the offering, who has a key to the building, who calls a family in crisis. The login is one more thing that runs on the same kind of trust.
The habit that actually holds is simple: agree out loud, once, on what each person looks at and what they leave alone. Not “the treasurer has access to giving” — there is no such access to grant — but “the treasurer is the one who opens the giving screens; the rest of us don't go looking.” Say it in a meeting. Write it in the same place you keep the password. Revisit it when the team changes.
Dividing the work without dividing the account
One login does not mean one person does everything. Most teams settle into an informal split that maps to who is already doing the work outside the software:
- The secretary or admin handles the directory, follow-up, and anything that touches the whole congregation.
- The treasurer is the one who opens giving and runs the year-end statements, by agreement rather than by lock.
- A volunteer coordinator owns serving teams and the schedule, since they are already the one fielding the texts about who is covering Sunday.
- The pastor tends to be the one who looks at pastoral care and reads the dashboard, more out of role than requirement.
None of this is enforced. It is simply who tends to open which screen, because it matches who already owns that piece of church life. Naming it out loud once removes most of the friction that would otherwise show up as duplicated effort or two people editing the same record a week apart. This same logic runs through a light weekly admin rhythm — a short, regular pass through the software where each person does their part rather than everyone doing everything at once.
What genuinely cannot be protected
Be honest with your team about the limit here, because it is real. With one shared login, anyone who signs in can see everything the account can see. There is no way to let the serving-team volunteer see the schedule but not the pastoral care notes, or let a new admin see the directory but not past giving. If a category of information is sensitive enough that certain people should truly never encounter it, that has to be handled by who gets the password and what they are asked not to look at — not by a setting inside the software.
For most small churches this is a manageable trade, because the people who share the login are already trusted with far more sensitive things: keys, cash, confidences shared in the hallway after service. But it is worth saying plainly in a team meeting rather than assuming everyone already understands it. “Anyone signed in can see anything in here” is a sentence worth saying out loud once, so nobody is surprised later.
Password hygiene for a shared account
A shared login only works if the password itself is treated with some care, which mostly means resisting the two easiest bad habits: writing it on a sticky note by the office computer, and never changing it. A short, boring routine covers most of it — store it in a password manager the whole team can reach, rotate it whenever someone with access leaves the team on any terms, and avoid texting it around in a group chat that outlives the current volunteer roster. None of this requires new software or a new process; it is the same basic hygiene you would want for a shared email inbox or a church Wi-Fi password.
This matters most at the exact moment a team changes — a volunteer moves away, a staff member is let go, a season ends and the roster turns over. That is also, not coincidentally, the moment follow-up and other ongoing threads tend to drop, so pair a password rotation with a quick handoff conversation about what was in progress, not just a new set of characters.
When your team is genuinely growing past this
A congregation of 60 sharing one login rarely feels the strain. A congregation of 300 with paid staff, several ministries, and real turnover sometimes does — and that is a legitimate sign to look at software built for a bigger structure, with actual role permissions and an IT-style admin. There is no shame in outgrowing a tool built for a smaller shape; the mismatch shows up as more hallway conversations about “who is supposed to see this,” not as a technical error. If you are still weighing what size of tool your church actually needs, that decision is covered directly in choosing church management software.
Most churches in the 60-to-250 range, though, find that the honest limits of one shared login are a fair trade for something simpler to run: no roles to configure, no permissions to audit, no admin console to learn. The work still gets divided — it is just divided by conversation and habit instead of by a setting, which turns out to be a familiar way for a small church team to operate.