Almost every “I can’t see that channel” or “why can they edit our files?” conversation traces back to one thing: roles. Collaboration platforms assign capabilities through roles — owner, member, guest — and most workplace confusion about access comes from people holding roles they didn’t know they had, or lacking ones nobody assigned.
This guide explains the role model shared by most modern platforms, what each role can typically do, and how to assign them without creating either bottlenecks or surprises. It’s written vendor-neutral on purpose; where platforms differ, we say so.
Why roles exist at all
Roles exist for the same reason door locks have different keys: not because information is equally sensitive, but because change is riskier than view. A workspace where everyone can restructure everything is one accidental drag-and-drop away from a bad week. A workspace where nobody can change anything is a museum.
Roles distribute the ability to change: few people hold the keys to structure (owners), many hold the ability to work (members), and outside collaborators get the narrowest slice that still lets them contribute (guests).
The three core roles
The names vary slightly between platforms, but nearly all of them implement this triad:
| Role | Typical capabilities | Typical risk if over-assigned |
|---|---|---|
| Owner | Full control: settings, members, structure, deletion | Unintentional structural changes; unclear accountability |
| Member | Participate: chat, files, most channels | Broad visibility of content not everyone should see |
| Guest | Limited access to specific teams or channels only | External exposure if scoped carelessly |
Above these sit workspace- or tenant-level administrators, who control platform-wide settings — who can create teams, whether guests are allowed at all, retention policies. If a capability described here is missing in your environment, an admin policy is usually the reason.
What owners typically control
- Membership: adding and removing people, approving join requests.
- Structure: creating, renaming, and deleting channels; archiving the team.
- Settings: naming the team, setting guest availability, managing tabs and connected apps.
- Delegation: promoting other members to owner.
Two owner habits prevent most problems: keep at least two owners per team — a single owner who leaves the company strands the team — and keep an owner list you can audit, because ownership drifts silently as teams reorganize.
Members and their expectations
Members are the working majority. They can converse, create and edit files, and usually create channels — though some organizations restrict channel creation to owners to prevent sprawl (a trade-off covered in organizing a growing workspace).
The member question that actually matters is visibility: by default, members see every standard channel and its history. If parts of a team’s work are sensitive — personnel matters, financial planning — the answer is a private channel or a separate team, not a culture of “don’t scroll up.” Decide deliberately which content is restricted, and document why.
Guests: collaboration without full access
Guests are people outside your organization: clients, vendors, contractors. The defining property of a guest is scope — a guest sees only the specific team or channel they were added to, not the workspace at large. Depending on platform and admin policy, guests may also be restricted from certain file actions or from discovering other teams.
Because guest access crosses an organizational boundary, it deserves its own process: who can add guests, what they’re told about norms, and when access is reviewed. That process has its own guide — A Practical Guide to Guest Access in Collaborative Workspaces.
Choosing the right role
A few rules of thumb that hold across platforms:
- Default to member. Owner is an administrative role, not a seniority badge. Grant it for accountability, not status.
- Two owners, rarely more than three. Each additional owner multiplies the ways structure can change accidentally.
- Guest for anyone without a company account — including long-term contractors, if your policy allows. Scope beats memory.
- Private channels for sensitivity, not convenience. If the reason someone shouldn’t see content is “they’d ask questions,” that’s a conversation to have, not a permission to set.
Assigning and reviewing access
Roles decay through ordinary organizational change: people switch teams, projects end, guests finish contracts. A quarterly 15-minute review per team catches most of it:
- Owners: still present, still appropriate, still at least two?
- Members: anyone who left the company or moved on?
- Guests: anyone whose engagement ended? (Guest lists drift the most.)
- Private channels: still private for the original reason?
Fold this into the broader workspace review described in Reviewing and Improving Digital Collaboration Practices — the same session that checks channels and files can check people and roles.
Permissions vary by edition and platform
For example, Microsoft Teams administrators can control team creation, guest access, and external communication through its admin center; Slack workspaces and Google Workspace domains expose similar controls with different defaults. The role vocabulary here travels well; the exact switches don’t. When instructions matter, test in your own tenant rather than trusting general articles — including this one.
For the adjacent problems — external collaboration in depth, and the diagnostic path when a role change breaks access — continue with the guides above or browse the full library.