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
- People: anyone with editor access on the project, including its creator. Guests can't invite people.
- Teams: workspace admins and owners who created the project or have editor access to it.
- The workspace: the project creator, or a workspace admin or owner with editor access to the project.
Being a workspace admin or owner doesn't give you access to every project in the workspace. Admins and owners reach a project through the same routes as everyone else, listed below.
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 workspace. Every non-guest workspace member gets the role the workspace was given — on the whole project, or on selected interfaces and field apps.
- 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
The people list in the Share dialog ends with a Workspace row for the project's workspace. Its Access dropdown works like a person's:
- No access — the project isn't shared with the workspace. New projects start here.
- Editor, Collaborator or Field worker — every member of the workspace gets the project at that role, including people who join the workspace later.
For Collaborator or Field worker, the Apps menu on the same row narrows the workspace to specific interfaces and field apps, just as it does for a person.
Each member gets the lower of the workspace's role and their own seat. The info icon next to the workspace's name says how many members their seat limits, and to what.
Guests and deactivated members never get access through the workspace. If you need a guest to see a project shared with the workspace, add them directly or through a team.
Only the project creator, or a workspace admin or owner with editor access to the project, can change the workspace's access. Other editors see the row but can't change it.
Choosing a role for the workspace
The seat cap is applied every time a member opens the project, so their access follows their seat. Upgrade someone from a collaborator seat to an editor seat and they become an editor on every project shared with the workspace at Editor.
Share with the workspace at Collaborator when members should work through the interfaces on this project whatever their seat. A member upgraded to an editor seat stays a collaborator on it. Give the people who need to edit it editor access directly or through a team.
Duplicating a project within its workspace keeps the original's workspace role. A workspace share limited to selected apps isn't copied.
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 a Workspace row with the access the whole workspace has. 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 | Set the Workspace row in the Share dialog to No access, or to a lower role — but note this changes 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. If they can open the project but not a particular interface or field app, check the Apps menu on the Workspace row — the workspace may only have access to selected apps.
"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.
"We upgraded their seat to editor, but they still can't edit a project shared with the workspace." Check the Workspace row. If the workspace has the project at Collaborator or Field worker, that is the most anyone gets through the workspace, whatever their seat. Give them editor access directly or through a team, or raise the workspace's role.
"They created the project but were removed from the workspace — what happens to the project?" While you remove them, Atlas asks you to transfer each project they created to another member with an editor seat. If nobody else has editor access to a project — directly, through a team, or because it's shared with the workspace at Editor — you can delete it instead. A workspace share at Collaborator or Field worker doesn't count as editor access here.