There are two ways a volunteer-run community handles permissions, and both are bad.
The first is one person with all the access. Everything works until they're on a plane, and then nothing works. The second is everyone with all the access, usually arrived at by accident after the fourth time someone needed something at 21:00. Now nobody knows who changed the training times.
The useful middle isn't complicated, but it does need deciding on purpose rather than by accumulation.
The single-admin club is one holiday from a crisis
If you can only answer "who can add a member, change an event or reach everyone at once?" with one name, that's your actual risk register.
It's also unfair to the person holding it. Being the only admin means every small request routes through you forever: adding a member, fixing a typo in a time, giving the new treasurer access to a document. None of it is hard, all of it is interruption, and it's the fastest route to a burnt-out organizer.
Delegation isn't just resilience. It's how you keep the volunteers who are good at this.
Two questions before you grant anything
Whenever someone asks for access, ask two things:
- What is the specific thing they can't do today? Not "they help with the youth team" but "they need to post in the youth channel and edit youth training times". Vague requests turn into broad access.
- What is the worst thing that happens if this goes wrong? Posting in a channel is recoverable in seconds. Removing thirty members, or messaging the entire community at once, is not.
Cheap and reversible: grant it, move on. Expensive or irreversible: keep it with a small, named group of people.
Delegate by group, not by person
The instinct is to think in people. Mette is sensible, give Mette access. The problem is that Mette is sensible about the youth team and has no reason to be editing the board's documents.
Think in groups instead. The youth team, the Thursday walkers, the committee, the trip to Berlin: each is a place with its own conversations, its own events, its own files and its own leads. Give the lead of each group real authority inside it and nothing outside it.
This scales in the way person-based access doesn't. When the youth coordinator changes, you change one lead in one group. Nobody has to audit what that individual accumulated over three years.
What a group lead actually needs
For most communities, a group lead needs to:
- Post and pin in their group's channels
- Create, edit and cancel their group's events
- See who has responded, and chase the people who haven't
- Add and organize their group's files
- Add members to their group
That's a genuinely useful amount of autonomy, and none of it can damage the wider community. The lead stops waiting on you, and you stop being a bottleneck for the youth team's Tuesday.
What should stay central
A short list, deliberately:
- Removing members from the community entirely
- Changing what the default permissions are for everyone
- Messaging the whole community at once
- Billing, legal, and anything with the club's name on it outside the club
Small group, ideally more than one person so it doesn't recreate the single-admin problem, and each of them should know they hold it.
The step everyone forgets: taking access back
Communities are extremely good at granting access and almost comically bad at removing it. Ask any club who has admin rights and you'll usually find a former treasurer, someone's old phone, and one person nobody can identify.
Tie removal to the thing that actually happens, which is a role ending:
- When someone stops being a group lead, their extra access ends that week, not eventually
- When someone leaves the community, check what they had beyond membership
- Once a season, read the list of everyone with elevated access out loud at a committee meeting. It's a two-minute agenda item and it works.
The point isn't distrust. It's that access nobody is reviewing is access nobody is responsible for.
A starter model you can copy
If you want something to adopt this week:
- Members can read everything for the groups they belong to, respond to events, and talk.
- Group leads can do anything within their own group, including events, files and adding members.
- Community admins, two or three people, can change community-wide settings, remove members and message everyone.
- Every elevated role has a named holder and an end condition, even if that condition is "reviewed each August".
That's enough structure for a club of five hundred and light enough for a club of twenty.
One more thing about defaults
The most consequential setting in any community isn't who's an admin. It's what an ordinary member can do by default: post, invite a friend, create an event, upload a photo.
Set that deliberately and early, because it defines the culture. A community where members can start things feels alive. A community where every action needs an admin feels like a queue, and eventually people stop joining the queue.
Steal the model above, whatever you run it on. If you want to see how spaces, groups, group admins and default permissions map onto it, that's on the features page.