The quality of a docs workflow depends heavily on who can access the project and what they are allowed to do. Doxbrix separates project-level membership from bro...
The quality of a docs workflow depends heavily on who can access the project and what they are allowed to do. Doxbrix separates project-level membership from bro...
The quality of a docs workflow depends heavily on who can access the project and what they are allowed to do. Doxbrix separates project-level membership from broader workspace access so teams can keep documentation work controlled without overcomplicating collaboration.
This guide explains how to use Project Members effectively, including direct membership, inherited access, and role assignment.
Who this is for
- project owners and docs leads
- teams adding more contributors or reviewers
- teams that need tighter project-level access control than workspace-wide permissions alone
What you can manage in Project Members
In Project settings → Project Members, you can:
- add a workspace member directly to the project
- assign a role of Viewer, Editor, or Admin
- review direct and inherited access
- search and filter members
- remove direct access from the project
Understand direct vs inherited access
Before making changes, understand the two access paths shown in Project Members:
- Direct members
- Inherited access
Direct members are people you explicitly add to the project.
Inherited access comes from the workspace. For example, workspace owners or admins may already have project access automatically.
The section also surfaces membership summaries such as:
- Total members
- Direct members
- Inherited access
- Eligible reviewers
Use these numbers to understand whether the project is tightly managed or broadly exposed.
Step 1 — Decide which people actually need project access
Before you add members, define the operating model.
Ask:
- who only needs to read the docs?
- who will actively author or edit content?
- who should manage project settings and access?
- who needs to participate in review workflows?
If those answers are unclear, access tends to expand without intention. Clean membership starts with a clear role model.
Step 2 — Add a member directly to the project
Use the Add member area to give a workspace member access to this project.
In Add member, use Select workspace member to choose the person you want to add.
Set Role to Viewer, Editor, or Admin based on the work that person needs to do.
Click Add member to grant project access.
Step 3 — Choose the right role
Use roles conservatively. The goal is to enable work without giving broader control than necessary.
Viewer
Use Viewer when a person should:
- read documentation
- inspect work in progress
- participate with limited editing responsibility
This role is useful for stakeholders who need visibility but should not control the project.
Editor
Use Editor when a person should:
- create and update content
- collaborate on documentation changes
- contribute as a regular author
This is usually the default role for active docs contributors.
Admin
Use Admin when a person should:
- manage project-level settings
- control operational configuration
- maintain access and governance for the project
Reserve Admin for a small number of responsible owners. Too many admins usually leads to inconsistent operational changes.
Step 4 — Use search and filters to audit access
As projects grow, use the Project members table tools to keep access understandable.
You can filter by:
- role
- access source
- review eligibility
You can also use Search members... to find people quickly by name or email.
This is especially useful when:
- verifying that only the right people can edit
- reviewing who has inherited access
- confirming who is available for review workflows
Step 5 — Understand inherited workspace access
If Inherited access is present, review it carefully.
This usually means some users have access because of workspace-level privileges rather than project-specific membership.
That matters because:
- removing a person from direct membership may not fully remove their access
- project leads may assume the wrong access boundary
- high-sensitivity projects often need a closer review of workspace roles
Step 6 — Remove direct project access when needed
When someone no longer needs project access, remove them from the direct project member list.
Use removal when:
- a contributor changes teams
- a reviewer is no longer assigned to the project
- temporary launch support has ended
- an external collaborator no longer needs access
Remember that removal affects direct project access, not the person’s broader workspace membership.
Step 7 — Keep roles aligned with governance
Project membership should support the way your team actually works.
Review access whenever you change:
- ownership expectations
- reviewer assignments
- approval policies
- launch responsibilities
- AI or API operational responsibilities
Membership drift is common in growing teams. A brief access review each month is usually enough to keep the project controlled.
Recommended operating pattern
For most teams:
- keep Admin limited to docs leads and operational owners
- use Editor for active contributors
- use Viewer for stakeholders and occasional participants
- review inherited access before assuming the project is tightly restricted