To share a project, open it and click Share in the top-right corner. This page explains how to invite people, which role to give them, how Atlas decides what each person can do, and how to remove access again.
To share a single interface rather than the whole project — publishing one dashboard, or inviting a client to just one view — see Sharing one interface.
Choose a role
Every person you invite gets one of three roles: Editor, Collaborator or Field worker. Editors build the project. Collaborators work through the interfaces you share with them, editing through popups, tables, forms and widgets depending on how you configure them. Field workers are collaborators with access to the field app. See Roles and access for the side-by-side comparison.
A team gets the role you give it, capped at each member's workspace seat.
Invite people
- Open the project and click Share.
- Under Invite people, add people or teams by name or email. You can add several at once.
- Pick the role for the invitation. For collaborators and field workers, choose whether they get the whole project or only specific interfaces and field apps.
- Optionally add a message, then send the invitation.
People who are already members of your workspace get access immediately. People outside the workspace receive an email invitation; they need an Atlas account to accept it, and can create one during the acceptance process.
Atlas requires a verified email address before granting access. If a recipient has not yet verified their email, clicking the invitation link takes them to a verification page. Once they verify — from any browser or device — Atlas automatically carries them to the invited project. If the invited email already belongs to an active Atlas account with a verified email, the invitation is resolved automatically and that person gains access without clicking the link.
Seats and plans
Inviting someone from outside your workspace adds them to the workspace as a guest and uses a seat of the role you picked. The Share dialog tells you how many seats the invitation will use before you send it.
Collaborator and field worker seats are included on the Team plan and above. On Free and Pro, everyone you invite is added as an editor — the dialog warns you when this is about to happen. See Billing and plans to add seats or change plan.
Only workspace admins and owners can invite people from outside the workspace.
Who can share a project
- The project creator.
- Anyone with editor access on the project.
- Workspace admins and owners, for any project in the workspace.
The ways access can be granted
A person can end up with access to a project through any of these routes:
- They created it. The creator always has full edit access.
- They were added directly. Invited through Share as an editor, collaborator or field worker, to the whole project or to specific interfaces and field apps.
- The project is shared with the whole workspace. Every non-guest workspace member gets the project at their seat's level — editors can edit it, collaborators and field workers get its interfaces.
- They belong to a team that was given access. See Teams.
- The project is public. Anyone with the link can use its public interfaces, optionally gated by a password.
A person can hit several of these at once — for example, a direct collaborator share plus a team grant. Atlas combines them:
- It picks the highest access level across every route that applies (editor beats field worker beats collaborator).
- It then caps that level by the person's seat in the workspace. A collaborator seat can never open the project editor, no matter how many editor-level grants they collect.
So the effective access is: (best grant you have) capped by (your seat).
Sharing 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
A project can be made publicly viewable, optionally behind a password. Public access gives visitors collaborator-level access at most — they can use the public interfaces, but never open the project editor.
Review who has access
There are two surfaces for looking at and changing access, depending on which direction you're asking the question from.
Starting from a project — "who has access to this project?" Open the project and click Share. The dialog lists people added directly, the teams the project is shared with, and the toggle to share the project with the whole workspace. Each entry shows the role they have. Change a role with the dropdown next to the name; remove someone from the menu next to it.
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.
For managing teams themselves, 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 (as editor, collaborator or field worker) | 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 under Workspace settings → Members. 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.
Removing someone from a project or a team does not remove them from the workspace. They keep their seat and any other project access they've been given. To fully off-board someone, remove them from the workspace.
Copy link
Copy link in the Share dialog copies the project URL. Anyone who already has access can open it directly; anyone else sees a sign-in or access-request prompt, unless the project is public.
If you just need to put a map in front of someone quickly, making an interface public and sending the link is often simpler than inviting them. See Public links and passwords.
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 collaborator or field worker seat caps them at their seat's level no matter what project access they have. See Roles and access.
"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.