Wiki Access Control: How to Manage Permissions for Large Teams

TL;DR

• Role-based access control (RBAC) means you give wiki access to roles and groups, not to individual people.
• Roles say what someone can do, groups say who gets that role, and spaces say where it applies.
• Give every permission to a group, start each group with the least access it needs, and check your settings on a set schedule.
• Below you'll find six design steps, a sample permission matrix, and common mistakes to avoid.

Say your company wiki worked fine when you had 40 people. Everyone could see everything, and you didn't mind, because there wasn't much to hide. Then the company reorganized. Two teams merged, a few contractors joined for a client project, and HR started keeping notes in your wiki too.

Now, imagine someone in sales opening a page about an HR case. It wasn't meant to be public. The page was just in a space everyone could open, because that's how you had always set it up.

Soon HR wants to know who else has seen it, since the case is sensitive. You can't say, because finding out means opening every space and checking its members one by one. A permission plan fixes that, and this guide shows you how to build one that keeps working as your team grows.

What Is Role-Based Access Control in a Wiki?

Role-based access control (RBAC) means you give access to roles, not to individual people. Someone gets a role, and the role comes with the permissions. In your wiki, that means you decide access once for a whole team, instead of page by page and person by person.

Four terms do most of the work:

Put together, a rule reads like this: the Engineering group can edit the Engineering space.

That one rule covers everyone on the team, including people you haven't hired yet.

Why Large Teams Outgrow Individual Permissions

Giving access person by person feels quick and easy when your team is small, but as you grow, it stops working for a few reasons:

• You add every new hire one space at a time: Each one needs you or an admin to add them to every space they need, and something always gets missed.
• You miss spaces when someone leaves: When a person leaves or changes teams, nobody remembers every space they were added to.
• You can't say who sees what: If your manager asks who can open the finance space, the honest answer is "let me check," followed by a lot of clicking.

How to Design Wiki Permissions in Six Steps

Step 1: Sort Your Content by Sensitivity

Before you change any settings, make a list of what's in your wiki, then decide how open each kind of content should be. Three levels are a good place to start:

The rest of the steps build on these levels, so meet with your team leads and agree on what counts as open, team-only, and confidential before you move on.

Step 2: Use Spaces as Your Permission Boundary

Each space has its own access rules, so treat each space as a fence. Create one space per team, per project, or per sensitivity level, and keep content with different access needs in different spaces.

If one page needs tighter access than the rest of its space, you have two choices. You can move it into a space with tighter access, or, if your wiki supports it, restrict that single page. Moving it is usually easier to keep track of, because the space's member list tells you exactly who can see it.

Step 3: Keep Your Role List Small

Every extra role is one more thing you have to explain and one more thing that can go wrong. These four roles are a solid starting point and cover a lot:

If someone asks you for a fifth role, check first whether a new group or a new space would solve the problem instead.

Step 4: Assign Groups, Not People

Give every permission to a group, even if the group only has one person in it today. That way, when someone joins, you add them to their team's group and they get the right access everywhere at once. When they leave, you take them out of the group and the access goes with them.

Give each group only the access its members need to do their work, and add more only when someone asks for it. Security teams call this least privilege, and it keeps a small mistake from becoming a big one.

Pick a naming pattern and stick to it. A simple one is the team name followed by the access level, like "Engineering Editors" or "Finance Viewers." Anyone looking at a space's member list, including you six months from now, can immediately tell why each group is there.

Step 5: Decide Who Creates Spaces and Manages Groups

If everyone can create spaces and change groups, your setup will get messy over time. So, pick a small set of owners, usually your Workspace Admins plus a few team leads, and send all requests through them.

The good news is that this doesn't need to slow anyone down. A short request form or a dedicated chat channel would work fine, as long as the same few people make the final call.

Step 6: Test What Each Group Can See

Before you announce the new setup, check it the way your users will see it. Create a test account, add it to one group at a time, and sign in to see which spaces show up.

Pay the most attention to your confidential level. If a test account in the sales group can open an HR space, fix it now, while the only person who saw it is you.

If you can, try your plan with the team that has the trickiest access needs, like HR or legal, before everyone else.

Sample Wiki Permission Matrix for a Large Organization

This is a made-up example to show how the pieces fit together. Note that your own spaces and groups will look different.

Write your own version of this table before you change any settings. It also gives the next admin a clear record of who's supposed to have access to what, so they don't have to piece it together from the settings.

Handling Contractors, Role Changes, and Departures

Your contractors and outside collaborators. Put them in their own group, separate from your staff groups. Add that group only to the spaces they need for their work. And when the work ends, you remove that one group from a few spaces and you're done.

People who change teams. Move them from their old team's group to the new one. And because access follows the group, their old spaces close and their new ones open in one step.

People who leave. Run through this checklist on their last day:

• Take them out of every group.
• Check each space for any access you gave them directly, outside a group.
• Hand their pages to a new owner. How to assign page owners and review dates in a wiki shows a simple way to do it.
• Remove their sign-in access.

Common Wiki Permission Mistakes

How to Review Wiki Permissions Over Time

A permission plan only keeps working if you check it from time to time. Checking is quick, and you can start with this schedule:

• Every quarter: Ask each Space Admin to look at the groups on their space and the people in those groups, and remove anyone who no longer needs access.
• Every time you create a space: Decide how sensitive its content is (open, team-only, or confidential), add the groups that need access, and check that the Everyone group isn't added to a space that should stay private.
• Every time someone leaves: Run the checklist above on their last day, because it's easy to forget a few weeks later.

Update your permission matrix whenever you change a group or a space. If the table and your settings don't match, find out why before you trust either one.

How Docmost Handles Wiki Permissions

Docmost gives you three layers to work with: your workspace, your spaces, and your pages. Restricting single pages is a paid edition feature, covered below.

Workspace Roles, Space Roles, and Groups

Everyone in your workspace has one of three roles: Owner, Admin, or Member. Owners have full control of the workspace, Admins manage spaces and users, and Members work in the spaces they've been added to. The Workspace Admin role from earlier is an Owner or an Admin.

Each space has its own member list, and you give each person or group on it one of three space roles. Full Access lets someone manage the space, its members, and its pages. Can Edit lets them create and change pages, but not manage members. Can View is read-only. These match the Space Admin, Editor, and Viewer roles used earlier in this post.

Whoever creates a space gets Full Access to it. The Docmost Spaces guide shows you how to add members step by step.

You add a group to a space the same way you add a person, and everyone in the group gets that role. Only Admins and Owners can create groups or change who's in them. The Docmost Groups guide covers setup.

Two Things to Check Before You Add Groups to Spaces

Keep these two details in mind:

• The Everyone group: Docmost has a built-in group called Everyone, and every user in your workspace is in it automatically. If you add Everyone to a space, your whole workspace gets in. Use it for open spaces like your company handbook, and keep it off team-only and confidential spaces.
• The highest space role wins: If someone can get into a space in two ways, like on their own and through a group, Docmost gives them whichever role is higher. So if a person has more access than you expected, check whether they were also added to the space directly.

Page Permissions in Docmost (Paid Edition)

On the paid edition, you can set a page's access level to Restricted so only the specific people and groups you select can access it. You can assign each member Can View or Can Edit access for that page.

When you restrict a parent page, every child page under it automatically inherits those restrictions. If a user's space role and page role conflict, Docmost applies the stricter permission of the two. For example, a person with Can View access at the space level can't edit a page, even if you give them Can Edit on that specific page.

Restricted pages disappear entirely from the sidebar tree and search results for anyone without permission to open them. For complete details, check out the page permissions guide.

Groups From Your Sign-In System (Paid Edition)

If your company uses single sign-on (SSO) through OIDC or SAML, or signs in through an LDAP directory, Docmost can refresh each person's group memberships automatically every time they sign in. It reads the groups your sign-in provider or directory sends once you turn on group sync. Note that you'll need to create the matching groups in Docmost first. The OIDC, SAML, and LDAP guides show you the setup for each.

For automated provisioning, Docmost's Enterprise plan also supports SCIM, a standard for managing accounts automatically. Unlike group sync at sign-in, SCIM lets your sign-in provider create users and groups, keep group memberships in sync, and deactivate departing employees without deleting their content. While SCIM is on, it takes over group memberships from sign-in group sync. See the SCIM guide for details.

If you're still comparing platforms, see how Docmost compares with other team wikis or read how to choose a wiki tool for your team.

Why Can't Someone See or Edit a Wiki Page?

When someone tells you they can't open or edit a page in Docmost, work through these three checks:

• Their space role: A person with Can View on the space can't edit a page, even if the page itself gives them Can Edit.
• A restricted page above it: On the paid edition, restricting a parent page restricts everything under it, and a person needs permission on every restricted page above it to open it.
• A second way into the space: If they were added to the space directly and also through a group, Docmost gives them whichever role is higher. So if you remove one, they may keep the access from the other, which means you need to check both.

Frequently Asked Questions

1. What is role-based access control in a wiki? 

It's a way of managing wiki access where permissions belong to roles and groups instead of individual people. Someone gets access by joining a group, and loses it when you take them out.

2. Should I assign wiki permissions to groups or individual users? 

Groups, almost always. Access you give to individuals is hard to track and easy to forget when someone changes teams or leaves. Even a one-person group is easier to manage later than a direct grant.

3. What's the difference between RBAC and attribute-based access control? 

RBAC gives access based on the role or group someone belongs to. Attribute-based access control (ABAC) decides access by checking details about the person, the content, the action, and sometimes the situation, like the time or location. NIST's ABAC guide has the full definition.

4. How does SSO relate to wiki permissions? 

Single sign-on controls how people sign in. Permissions control what they can see and do once they're in. On the paid edition, Docmost can also keep your groups up to date from your SSO or LDAP sign-in once you turn on group sync, so you don't have to add people to groups yourself.

5. What's the difference between SSO and SCIM? 

Single sign-on controls how people sign in. SCIM lets your sign-in provider create users and groups, keep memberships in sync, and deactivate accounts, and it's an Enterprise plan feature. Group sync at sign-in only refreshes groups when someone signs in.

6. Do small teams need role-based access control? 

Not on day one, but it's easier to set up groups early than to untangle individual access later. Even if your team is small, one group per team and one space per sensitive topic is a good start.

Give Every Team the Right Access With Role-Based Access Control in Docmost

If you're planning a wiki for a large team, get a free trial license to try the paid edition's features yourself, or contact the Docmost sales team to talk through your spaces, groups, and access.