Project Access & Overrides
Project access answers two questions at once: can this person open the project, and what role do they get inside it. Both are set on the project, not on the person — a default that covers the whole workspace, plus exceptions for the few people and groups who need something else.
There is no membership list
Nobody has to be added to a project before they can work in it. Every project carries a default that applies to everyone in the workspace, and a person with no exception on that project simply gets the default. A user created this morning, never mentioned on any project, can open every project in the workspace on its default terms.
That is a change in shape from a membership model: access is now expressed as “everyone, except…” rather than as a list of people who were let in.
The default
A project’s default is one of two things, set in the project’s Access panel:
| Default | Role inside the project |
|---|---|
| Their own workspace role | Whatever Role each person carries across the workspace. |
| One role for everyone | A single role you pick, applied to everybody who has no exception, whatever they are elsewhere. |
A person with no Role gets nothing from the first option. On a project set to their own workspace role, a workspace member who has never been given a Role has nothing to inherit — the project does not appear in their Projects list at all. The same person can open a project that hands one role to everyone. If someone reports that most projects are invisible to them, check their Role first.
Exceptions
Each project keeps a short list of exceptions — people and Access Groups handled differently from the default. There are three modes:
| Mode | Effect |
|---|---|
| No access | The project is hidden from them entirely. |
| Their workspace role | They use their own Role here, even where the project hands one role to everybody else. |
| A specific role | A role that applies in this project only. This is the per-project override. |
How a person’s access is decided
- If they have a personal exception on the project, it decides.
- Otherwise, if a group they belong to has an exception, that decides.
- Otherwise the project default applies.
A personal exception beats a group one. Driven live: a user in a group that was set to No access on a project, but who also carried a personal exception of Their workspace role on that same project, could still open it. The personal rule won.
How to give someone a different role in one project
- Go to Settings → Projects and choose Manage access… in that project’s row menu.
- In the Exceptions panel, click Add person and pick them. The new exception starts at No access.
- Change the mode to A specific role and choose the role.
- Click Save changes. Nothing is written until you do.
To take the override away, click the × on their row and save. They go back to the project default.
Changing someone’s workspace Role
Changing a user’s Role in Settings → Users changes what they can do in every project that resolves to their own role for them. It does not touch a project where they have a A specific role exception, or one that hands a single role to everybody.
“How do I give someone access to only one project?” Not by adding them to it — by excluding them from the others. Give the project you want them in whatever access they need, then add a No access exception for them (or for a group they belong to) on the projects you want closed. There is no setting that means “this person sees nothing by default”.