Organizations often use the word role for three different ideas. Treasurer may describe a real-world responsibility. Finance Committee describes where someone participates. Administrator describes what the person is allowed to change in a system.
When those ideas are collapsed into one label, responsibility becomes harder to explain and access tends to spread further than necessary. Separating them creates a clearer organization and safer software decisions.
A role describes responsibility
An organizational role answers: What is this person accountable for? Chair, treasurer, secretary, volunteer coordinator, and section leader are examples. The title should help other members know whom to approach and what decisions the person owns.
A role can exist whether or not the organization uses software. It belongs to the organization's governance and working practices.
A committee describes participation
A committee, team, chapter, or working group answers: Where does this person contribute? Someone may belong to several groups while holding one organizational role—or no formal title at all.
Groups should be named around durable areas of participation and given a plain-language purpose. In ForGuilds, a group can also have an appropriate visibility level: Guild-wide, visible to Guild members, or private to assigned members.
A permission controls system access
A permission answers: What may this person view or change in the software? It should follow the work they need to perform, not the prestige of their title. A committee chair may need to participate in a private group without needing administrative control over the entire Guild.
ForGuilds currently expresses Guild access through owner, admin, and member roles. Owners and administrators maintain different parts of the workspace; ordinary members participate without receiving broad management access. This is deliberately simpler than a custom permission builder.
Test the model with real people
Consider a volunteer named Sam. Sam is the real-world Events Chair, belongs to the Events Committee and Welcome Team, and uses ordinary member access. Those three facts are compatible because each answers a different question.
Now consider Alex, the membership administrator. Alex may hold the Membership Secretary role, belong to the Membership Committee, and need admin access to manage invitations and member records. Access is justified by the work, not by committee membership alone.
- Role: What is the person responsible for?
- Group: Where does the person participate?
- Access: What must the person manage in the system?
Review access separately and regularly
When someone changes office, review all three layers. Their organizational title may end, their committee membership may continue, and their administrative access may need to be reduced immediately.
A short review prevents a common mistake: leaving software access in place simply because the person remains a valued member of the organization.
Responsibility, participation, and access are related—but they are not interchangeable.