Atlas logo
⌘K

Documentation

Getting Started
Data
Maps
Builder
Workflows
Forms
Sharing & Collaboration
Projects & Management
Connections

Sharing one interface

Make a single interface public, invite people to one interface, and choose what collaborators can change

In Atlas, sharing is interface-centric. The Share dialog lets you decide, per interface, who can see it and whether it's public — so you can publish one interface to the world, share another with a single client, and keep the rest private. Project-level access (workspace members and the project owner) underlies all of it; per-interface settings layer on top.

For the full invite walk-through (roles, teams, seat behaviour), see Sharing a project.

Public access toggle per interface

In the share dialog, the Public access section shows every interface in the project with a switch:

  • The master toggle at the top flips every interface to public or private at once.
  • Each row toggles a single interface independently. The badge shows whether each interface is Public or Private.
  • The header summary shows how many interfaces are currently public (e.g. "2 of 4 interfaces currently public").

Plan gating

Toggling individual interfaces requires the per-interface public access feature (currently included on Team plans and above). On plans without it:

  • The master toggle still works (everything public or everything private).
  • Per-row toggles show a lock icon and trigger an upgrade prompt when clicked.

A "Toggle interfaces individually" upsell card appears at the bottom of the section when this feature isn't on your plan.

Inviting people to an interface

The Share dialog's Invite people row lets you grant access to one or more interfaces by email or team name. Pick the role for the invitation:

  • Collaborator — can open the interfaces you chose and use them: browse the map, comment, and edit through popups, tables, forms and widgets depending on how you've configured them (see below). Can't open the project editor or reach other interfaces. Uses a collaborator seat.
  • Field worker — a collaborator with access to the field app: everything above, plus the project's Field Apps in the Atlas mobile app. Uses a field worker seat.
  • Editor — full editing access to the whole project. Uses an editor seat.

See the Compare roles table for the full breakdown.

Seats and plans

Collaborator and field worker seats are included on the Team plan and above. On Free and Pro, people you invite are added to the workspace as editors instead — they get edit access to the whole project, not just the interface. The dialog warns you before this happens, so plan accordingly when sharing externally.

People from outside your workspace are added to it as guests. Only workspace admins and owners can invite them.

What collaborators see

A person invited to a single interface as a collaborator:

  • Lands on the shared interface URL.
  • Cannot navigate to other interfaces in the project unless they're also public.
  • Cannot open the project editor or change the layout, styling or settings.
  • Can interact with the map, widgets, forms and comments — and edit data through whichever popups, tables and widgets you've opened up.

Letting collaborators change data

An interface is read-only for collaborators until you say otherwise. Each place that can write data has its own switch, off by default, so you decide exactly what they can touch without ever giving them the project editor. The same switches apply to anonymous visitors on public interfaces.

  • Popups — turn on Enable collaborator editing in the popup settings to let anyone who can see the popup click a field value and edit it in place.
  • Tables — the table widget has an Allow collaborator editing option that lets people edit cells directly. System columns, computed, relation, lookup, and formula fields stay read-only regardless.
  • Data-entry widgets — buttons that add or update records, upload widgets and forms write data on the collaborator's behalf, limited to the columns you configured. Atlas validates every submission against the widget configuration before writing.

See Widgets for the per-widget settings.

Practical examples

  • Public report + private dashboard: keep the internal dashboard interface private; flip the public-facing report to Public.
  • Client review: invite a client by email as a collaborator on the "Client review" interface only. They never see the team's working interfaces.
  • Collaborator data entry: enable collaborator editing on a table or popup so a partner can fill in records without needing an editor seat.
  • Field crew: invite the crew as field workers on the "Inspections" interface. They get the interface on the web and the field app on their phones.
  • Embed: combine public access with Embedding a map to drop a single interface into another website.

Limits and notes

  • Visibility changes propagate immediately; refreshing the collaborator's tab is enough.
  • Workspace members of the underlying project still see every interface they have project-level access to — per-interface invites grant access to outside guests, they don't take access away from existing members.
  • Audit who has access by reviewing the people-with-access list in the Share dialog regularly.
PreviousSharing a projectSharing & Collaboration
NextPublic links and passwordsSharing & Collaboration