Project Access
The project access editor controls which users and groups can access a project, and with what role. It is opened via the Access button on any project row. Understanding how access modes determine the effective role is the key to configuring this correctly.
The access editor
The editor has two tabs with the same structure:
- USERS — set access rules for individual users
- GROUPS — set access rules for Access Groups, applying the same rule to every member of the group at once
Each row has an access mode dropdown. The mode you select determines the effective role — the role that is actually applied when that user works inside the project.
What is the effective role?
Every user in a project has an effective role — the role that governs what they can do. The effective role is not always the same as their Global Role. It depends on the access mode set for that user (or their group), and on whether a Project Role Override has been set on their workspace membership.
This table shows exactly which role wins for each mode:
| Mode | Effective role used | When to use it |
|---|---|---|
| Inherit (default) | The user's Global Role — unless they have a Project Role Override set, in which case the override wins | Standard setting for most users; respects whatever role they carry globally or any per-project override already set on them |
| No Access | None — the user cannot see or enter the project | Explicitly block a user who would otherwise have access (for example, via a group rule) |
| Force Global Role | Always the user's Global Role, even if a Project Role Override exists | Ensure a specific user always uses their global role in this project, ignoring any override |
| Force Role | A specific role you choose, regardless of their Global Role or any override | Give a user a different role in this project only — more or less permissions than their global assignment |
How role resolution works
When a user accesses a project, their effective role is resolved in this order:
- Is the mode set to Force Role? If yes, the role you selected is used immediately. No other setting matters.
- Is the mode set to No Access? If yes, access is blocked entirely. No other setting matters.
- Is the mode set to Force Global Role? If yes, the user's workspace Global Role is always used — any Project Role Override on their membership is bypassed.
- Is the mode set to Inherit?
- If the user has a Project Role Override set → the override role is used
- If no override is set → the user's Global Role is used
In short: Force Role gives you explicit, unconditional control. Inherit respects whatever the user's normal role chain resolves to. Force Global Role locks them to their workspace role and ignores any per-project override.
No Access overrides everything. Setting a user's mode to No Access removes all visibility into the project, regardless of their Access Level or Global Role. If a user reports they cannot see a project, check whether a No Access rule is applied to them directly or to a group they belong to.
"A user has a Project Role Override set — will it still apply here?" It depends on the mode. If the mode is Inherit, yes — the override is respected and becomes their effective role. If the mode is Force Global Role, the override is bypassed and their Global Role is used instead. If the mode is Force Role, the role you chose wins regardless of any override.
Group rules
Access groups apply the same four modes to every member of the group at once. This makes it easy to grant or restrict access for a whole team in one step.
Individual rules take precedence over group rules. If both a group rule and an individual user rule exist for the same user, the individual rule is used.
Example: Group "QA Team" is set to Inherit. User Alice is a member of QA Team but has an individual rule set to No Access. Alice cannot access the project, even though her group can.
For the full picture of how Global Roles, Project Role Overrides, and project membership interact across the four-tier model, see Project Access & Overrides.