Project Access
Project access is built out of a default and a short list of exceptions. Everyone in the workspace can open the project on the default terms; the exceptions name the few people and groups who get something else. There is no membership list to maintain, and nobody has to be added to a project before they can work in it.
Where it lives
Access is two of the three panels on a project’s own page: Access sets the default, Exceptions lists the departures from it. Reach them with Manage access… in a row menu on Settings → Projects, which opens the project page with the Access panel in focus, or with Edit project… and a scroll. Both panels save with the rest of the page — one Save changes covers the project’s name, its default and every exception.
The sentence at the top
The Access panel opens with a plain-language statement of the outcome, so you are reading a result rather than reconstructing one. It has two parts — what the default does, and how many people fall outside it:
| Setting | The sentence |
|---|---|
| Default, no exceptions | “Everyone in the workspace can open this project with their own role.” · “No exceptions.” |
| Default, one exception | “… 1 person is handled differently.” |
| Default, several exceptions including blocks | “… 3 people and 2 groups are handled differently — 2 of them cannot open it at all.” |
| One role for everyone | “Everyone in the workspace can open this project as Test Viewer.” |
The sentence updates as you change the controls beneath it, before you save.
Everyone gets
One control sets the project’s default: “The role people have in this project unless an exception below says otherwise.” It has two options:
- Their own workspace role — “Whatever each person already has”
- The default. Each person works in the project with the Role they carry across the workspace.
- One role for everyone — “Overrides their workspace role here”
- Picking this reveals a second field, That role — “Applied to everyone without an exception.” Everybody works in this project as that role whatever they are elsewhere. Saving without choosing one is refused with “Choose the role everyone gets.”
“Their own workspace role” gives nothing to someone who has no role. A workspace member with no Role assigned has nothing to inherit, so on a project set to their own workspace role they cannot open it — and the project does not appear in their Projects list at all. The same person can open a project set to One role for everyone, because that role is handed to them outright. Measured on a live workspace: a role-less user saw exactly one of seven active projects, the one with a role for everyone.
Exceptions
The Exceptions panel carries a total and then two sections, People and Groups, each with its own count and its own Add person / Add group button. A project with none reads 0, and each section explains itself:
- People: “Everyone follows the project default. Add a person only to give them something different.”
- Groups: “No group exceptions. Groups are managed in Users & access.”
Adding one
Add person opens a list of everyone who does not already have an exception, each with their workspace role beside their name; once the list is long enough it grows its own Search people box. Add group does the same over Access Groups, with the member count as the hint and a Search groups box. Picking someone leaves the menu open and removes them from the list, so adding four people is one open and four clicks.
A newly added exception starts at No access. Change it with the mode control on the row. The × at the end of the row removes the exception, putting that person or group back on the project default.
The three modes
| Mode | The product’s own gloss | What it means |
|---|---|---|
| No access | “Cannot open the project” | The project is hidden from them entirely — it does not appear in their Projects list or the switcher. |
| Their workspace role | “Ignores the project default” | They work in this project with their own workspace Role, even when the project hands one role to everybody else. |
| A specific role | “Only inside this project” | A role you pick, used here and nowhere else. A second control on the row holds the role. |
Choosing A specific role and leaving the role empty blocks the save with a message that names the person: “Choose a role for Ben Whitfield, or give them a different kind of access.”
People, groups, and no rule at all
There are only three states a person can be in for a given project:
- A personal exception — it decides, and nothing else is consulted.
- No personal exception, but a group they belong to has one — the group’s exception applies to them.
- No rule anywhere — the project default applies, which is the case for almost everyone.
Leaving someone without a rule is the normal state, not an omission. It means “treat them like everybody else”.
“Why can this person not see the project?” Two answers cover almost every case. Either there is a No access exception on them or on a group they are in, or the project is set to their own workspace role and they have no workspace Role to bring. Both are visible from this one page.
What the projects list shows
The Access column on Settings → Projects reports the default only — Everyone, own role or Everyone as <role>. It does not count exceptions, so a project with five of them looks the same in the list as one with none. Open the project to see who is handled differently.