Skip to main content

Add and manage users

Connect docs via MCP

Users are the people in your Atlan workspace, and each user's role sets the ceiling on what they can do, from the day they join to the day they leave. You add users by email or through your identity provider, give each one a role, and remove or downgrade them when they move on. Groups and personas decide which assets a user sees; their role decides what they are allowed to do with those assets.

Roles

Every user has exactly one platform-wide role. It sets the ceiling on what actions are possible across the workspace, no matter what their personas allow.

AdminIT & workspace owners

Full control. Manages users, SSO, connections, governance, and every workspace setting. Sees all assets; persona scoping does not apply.

MemberAnalysts & engineers

The everyday role. Browses assets, runs queries, and edits metadata, but only for the assets their persona grants. No access to workspace settings.

GuestStakeholders & externals

Read-only. Views the assets they are given access to, nothing more. Always capped at read-only, even with a persona.

Sub-roles

An Admin can grant a Member extra powers without making them a full Admin.

Governance AdminSub-role

Manages personas, purposes, and policies. Cannot manage users or workspace config.

Workflow AdminSub-role

Manages automation workflows and apps. Cannot touch governance or users.

What each role can do

Role controls what a user can do. Persona controls what a user can see. They evaluate separately. A Guest user in a persona that grants lineage access can see lineage; their role doesn't block it. But a Guest user cannot add announcements regardless of persona, because the Guest role is a hard ceiling on that action.

ActionGuestMemberAdminNotes
Search and discover assetsYesYesYesSubject to persona scope
View asset metadataYesYesYesLock icon where no edit access
Edit asset metadataNoYesYesGuest ceiling; persona cannot lift it
Add announcementsNoYesYesCounts as a metadata write, blocked at role level
Preview sample dataConditionalConditionalYesRequires explicit data policy allow plus the Labs toggle enabled
View lineageConditionalConditionalYesRequires persona to grant lineage tab visibility
Run queries in InsightsNoConditionalYesRequires data policy plus role-based Insights access
Suggest metadata changes (requests)ConditionalYesYesRequires Labs "Allow guests to raise requests" to be enabled
Create data quality rulesNoConditionalYesRequires Governance Admin sub-role for Members
Access AI ChatYes (limited)YesYesGuest can open AI Chat but cannot send follow-up messages; input is disabled after the first message
Connection Admin on a specific connectionYesYesYesConnection Admin status lifts the Guest ceiling for that connection's assets only
Access Insights nav / Domains navNoYesYesThese nav items do not appear for Guest role

A common question is whether a persona that grants access to a sidebar tab or asset overrides the Guest role. The answer depends on the action. Persona controls visibility (which tabs and assets appear). Role controls what actions are possible. A persona cannot grant edit access to a Guest, because that is blocked at the role level regardless of policy.

$guest and $admin in API responses

In API responses and admin exports, you may see $guest, $member, or $admin with a dollar-sign prefix. These are the internal system identifiers for the built-in roles. They are equivalent to Guest, Member, and Admin respectively. The prefix distinguishes system roles from custom roles.

Manage users and roles

See also