This is the part most people interact with day to day. There are several ways someone can end up with access to a project, and Atlas combines them to decide the final answer.
For per-interface access — making a single dashboard public, or inviting a guest to one specific interface — see Interface permissions.
The ways access can be granted
A project can be accessible to a person through any of these routes:
- They created it. The creator always has full edit access.
- They were added directly as an editor. Use "Share" on the project and add them with edit access — see Inviting Collaborators.
- They were added directly as a viewer. Same, but with view-only access.
- The project is shared with the whole workspace. Every non-guest workspace member can see (or edit, depending on their seat) the project.
- They belong to a team that was given access. See Teams.
- The project is public. Anyone with the link can view it. Optionally gated by a password.
A person can hit several of these at once — for example, a direct viewer share plus a team grant. Atlas combines them and picks the highest level of access they're entitled to.
How the final access level is decided
Two things happen:
- Atlas checks every route above that applies to this person and this project, and picks the highest access level (edit beats view).
- Atlas then caps that level by the person's seat in the workspace. A Viewer seat can never edit, no matter how many editor-level grants they collect.
So the effective access is: (best grant you have) capped by (your seat).
Sharing a project with the whole workspace
When you share a project with the workspace, every workspace member sees it — except guests. Guests are specifically excluded from workspace-wide sharing. If you need a guest to see a workspace-shared project, add them directly or through a team.
Public projects and passwords
A project can be made publicly viewable. Optionally you can set a password so only people who know it can open it. Public access always gives viewer-level access only — it cannot be used to grant editing.
Who can share a project
- The project creator can share it.
- Anyone with edit access on the project can share it.
- Workspace admins and owners can share any project in the workspace.
Where to manage access
There are two surfaces for looking at and changing access, depending on which direction you're asking the question from.
Starting from a person — "what can this member see?" Go to Workspace → Members. You'll see everyone in the workspace with their role and seat. Click a member to open their profile, which lists every project they can reach along with their access level on each one and the route they got it through — direct share, workspace-wide, or a named team. Admins and owners can view and change this for any member.
Starting from a project — "who has access to this project?" Open the project and use the Share dialog. It lists people who have direct access, the teams the project is shared with, and the toggle to share the project with the whole workspace.
For managing teams themselves (who's on them, who they're shared with), go to Workspace → Teams.
Removing or revoking access
How you remove access depends on how they got it. Because the same person can hold access through several routes at once, you often have to remove it from each route separately.
| Where the access came from | How to remove it |
|---|---|
| Added directly to the project (editor or viewer) | Remove them from the project's share list. |
| The project is shared with the whole workspace | Unshare the project from the workspace — but note this removes access for everyone in the workspace. If you only want to remove one person, remove them from the workspace instead, or move to team-based sharing. |
| They belong to a team that has project access | Either remove them from the team, or unshare the project from the team (which affects all team members). |
| The project is public | Turn off public access, or add a password. |
| They own the project | You can't "unshare" a creator. Either reassign ownership (if supported on your plan) or delete the project. |
To revoke all Atlas access from a person, remove them from the workspace entirely. This removes their seat, their workspace role, and their workspace-shared and team-based project access in one step. Direct shares they had on individual projects may linger — check each project's share list afterward if you want to be thorough.
Important: removing someone from a team does not remove them from the workspace. They still have their seat and any other project access they've been given. If you want to fully off-board someone, remove them from the workspace, not from a team.
Common questions
"Why can't a member see a project I shared with the workspace?" Almost always: they're a Guest. Guests don't receive workspace-wide shares. Share it with them directly or through a team.
"They have edit access on the project but can't edit." Check their seat. A Viewer seat caps them at view-only no matter what project access they have.
"They created the project but were removed from the workspace — what happens to the project?" The project keeps existing in the workspace. Workspace admins and owners can still manage it; sharing with the original creator is no longer meaningful since they're no longer a member.