Skip to main content
Project visibility is not a per-project setting. It is derived from your role’s supervision scope.

The rule

A role scoped to Everything in the workspace sees every project. Every narrower scope sees only the projects it manages or is staffed on.
That is the whole rule. There is no “private project” toggle and no per-project share list for internal staff.

What counts as staffed on

You can see a project when any of these is true: Nothing else grants reach. Being in a group does not. Being assigned a task in the project does not, unless you are also on the roster.

The five supervision scopes

Set on the role, at Settings → Roles.
Only the widest scope changes project reach. The three middle scopes differ in people reach – a group is not a project – but all of them limit projects to “yours”.
Full detail at /concepts/supervision-scope.

Default scope per role

Owner is pinned to workspace scope and cannot be narrowed – an owner who could be scoped down could lock themselves out. Client is pinned to the narrowest scope, because the portal firewall depends on it.

Capability is not scope

Two different questions, both of which must be answered yes. A project manager holding time.viewOthers still only sees the timesheets of people in their scope. Widening a role’s scope to see all projects does not by itself grant any new power – the capability still has to be there.

What follows project reach

Project reach is the spine. Three other things derive from it.
This is why there is no separate client visibility setting. One rule, applied once, means the two can never disagree and leave someone able to see every client but none of their projects.

What happens when reach changes

A project outside your reach is deliberately indistinguishable from a deleted one. That is what stops a stray link being used to probe what exists.

Example

Northwind Studio, four projects. Nobody is staffed on Brand Refresh except Tom, so Priya cannot see it – or Fenwick Legal, its client. When Priya adds Jonas to Website Redesign, Jonas’s list grows to two projects on his next screen update.

Client portal contacts are different

A portal contact is not scoped like staff. They see a project only when it is explicitly ticked for them on their client’s page, and only projects belonging to their own client company. See /portal/what-clients-can-see.

Where money adds a second gate

Even inside a project you can see, some figures are held back. These figures are omitted before they leave the server, not hidden in your browser.

Permissions

Common questions

Effectively yes – keep the roster small. Anyone at workspace scope still sees it, because that scope means the whole workspace by definition.
Not with one role. Scope governs both halves on purpose. A second setting would drift the first time somebody edited one and not the other. Build a second role if you genuinely need a different split.
Because they are on the member list, or because the role’s scope was widened to the whole workspace.
No. Add the person to the project roster.
You lost reach to their last visible project – it was archived, deleted, or you were removed from it.
An archived project is hidden from the active list for everyone. Switch the list to Archived or All to see it, as long as it is within your reach.

Troubleshooting

Supervision scope

The canonical explanation.

Roles and capabilities

The “may you” half.

Project members

How to grant reach.

Custom roles

Build a role with the right scope.

What clients can see

The portal’s separate rule.

Project permissions

What you can do once you can see it.