Summary and recommendation
Atlan user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Atlan user management lives in Settings → Users & Groups (https://<your-tenant>.atlan.com/governance/users).
Three base roles exist: Admin, Member, and Guest.
Admins hold broad destructive capabilities, so Atlan recommends keeping that count low.
Effective access in Atlan is never just a role - it is the intersection of three layers.
Base roles set platform-level capabilities.
Personas layer asset-type and UI-level permissions on top.
Purposes add classification-based row/column data-policy controls.
Every app has a permission model;
Atlan's three-layer hybrid is among the more granular ones you will encounter.
Quick facts
| Admin console path | Settings → Users & Groups |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Admin | Full platform administration: invite/deactivate users, manage roles, personas, purposes, integrations, and all governance settings. | Admin role grants broad destructive capabilities; Atlan recommends limiting the number of Admins. | |||
| Member | Standard access to the data catalog: search, view, request access, create and edit assets they own, collaborate via annotations and conversations. | Cannot manage users, change platform settings, or modify personas/purposes. | Effective permissions are further shaped by any Personas and Purposes assigned to the user. | ||
| Guest | Read-only access scoped to assets explicitly shared with them via a Persona or Purpose. | Cannot create assets, invite users, or access governance settings. | Guest users still consume a seat; confirm licensing implications with Atlan account team. |
Permission model
- Model type: hybrid
- Description: Atlan uses a three-tier hybrid model. Base roles (Admin, Member, Guest) set platform-level capabilities. Personas layer asset-type and UI-level permissions on top of base roles. Purposes add policy-based row/column-level data access controls tied to asset classifications. All three layers interact to determine effective access.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Role level (platform), Persona level (asset type and UI), Purpose level (classification-based data policy)
How to add users
- Navigate to Settings → Users & Groups.
- Click 'Invite users'.
- Enter one or more email addresses.
- Select the base role (Admin, Member, or Guest).
- Optionally assign one or more Personas.
- Click 'Send invite'. The invitee receives an email to set up their account.
Required fields: Email address, Base role
Watch out for:
- Invited users must accept the email invitation before they appear as active in the user list.
- Persona assignment at invite time is optional but recommended to avoid users having overly broad default access.
- If SSO is enforced, users must authenticate via the configured IdP on first login; password-based login may be disabled.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: No
- Delete/deactivate behavior: Atlan's official documentation describes deactivating users rather than permanently deleting them. Deactivated users cannot log in and do not consume an active seat, but their account record and associated metadata contributions are retained.
- Navigate to Settings → Users & Groups.
- Locate the user in the user list.
- Click the three-dot (⋮) menu next to the user.
- Select 'Deactivate user'.
- Confirm the action in the dialog.
| Data impact | Behavior |
|---|---|
| Owned records | Assets owned by the deactivated user retain the user as owner; ownership must be manually reassigned to avoid orphaned assets. |
| Shared content | Conversations, annotations, and glossary contributions created by the user remain visible in the platform. |
| Integrations | API tokens or service accounts tied to the user's identity may stop functioning; review and rotate tokens before deactivation. |
| License freed | Deactivated users are removed from the active user count, which may free a billable seat depending on the contract terms. |
Watch out for:
- Atlan does not automatically reassign asset ownership on deactivation; orphaned assets must be remediated manually.
- If the deactivated user was the sole Admin, another Admin must be promoted before deactivation to avoid losing administrative access.
- SCIM-provisioned users deactivated in the IdP are automatically deactivated in Atlan; manual deactivation in Atlan is not required when SCIM is active.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Active User | Any user with Admin, Member, or Guest role who has accepted their invitation and is not deactivated. | Custom pricing; varies by tier (Starter, Premier, Enterprise). Contact Atlan sales. |
- Where to check usage: Settings → Users & Groups - the user list displays active vs. inactive status and total user counts.
- How to identify unused seats: Filter the Users & Groups list by 'Last active' date to identify users who have not logged in recently. No built-in automated idle-user report is documented in official help content.
- Billing notes: Atlan pricing is custom and negotiated per contract. Tiers are Starter, Premier, and Enterprise. Seat counts and overage terms are contract-specific. Deactivated users should not count toward active seat consumption, but this should be confirmed in the signed agreement.
The cost of manual management
Inviting users requires entering each email address individually through the UI - no native bulk CSV import is documented. For large initial loads, that means every app onboarding event becomes a manual, one-by-one operation unless SCIM is active.
Deactivating a user does not reassign asset ownership. Orphaned catalog assets must be remediated manually after each offboarding, which adds recurring cleanup work proportional to how many assets the departing user owned.
Guest users consume a seat despite having read-only access. Because this is not prominently surfaced during onboarding, teams frequently discover unexpected seat consumption after the fact. Confirm Guest seat terms in your signed contract before provisioning external stakeholders at scale.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Choose manual management if your Atlan tenant is on Starter or Premier tier, your team is small, and user turnover is low. The invite flow is straightforward for single additions, and deactivation is a five-step process in the UI.
Switch to SCIM if you are on Enterprise, have SSO (SAML) configured, and need lifecycle automation. SCIM handles provisioning, attribute updates, and deprovisioning in sync with your IdP - eliminating the orphaned-asset and seat-count risks that accumulate with manual processes at scale.
If you are between tiers, weigh the operational cost of manual orphan remediation and seat audits against the Enterprise upgrade cost. The break-even point depends on headcount churn, not just total user count.
Bottom line
Atlan's manual user management is functional for small, stable teams but carries compounding overhead at scale: no bulk import, no automatic ownership reassignment on deactivation, and a three-layer permission model that requires careful configuration to produce predictable effective access.
Guest seats consume license capacity regardless of usage, so seat hygiene requires active monitoring. For any team with meaningful onboarding or offboarding volume, SCIM provisioning on the Enterprise tier is the operationally sound path - manual management is a starting point, not a long-term strategy.
Automate Atlan workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
