Design access, personas, and governance in Atlan

||Connect docs via MCP

Most access problems are solved by matching the simplest mechanism to your actual requirement—not by turning on more controls. This guide helps you choose between personas, purposes, domains, and governance workflows; sequence the rollout so it doesn't stall; and answer the recurring "who can see or do what" questions. It's written for the team standing up governance on a fresh or growing Atlan tenant.

When to use what

Resolve your requirement to one of these building blocks before you configure anything. Almost every rollout is solved with personas alone—reach for purposes, deny, or custom roles only when a concrete restriction genuinely needs them.

Your requirement	Use	Notes
"Role X needs to see or edit a connection or category Y"	Persona	The default. Scope by connection. Start with 2–3 tiers (view / contribute / admin).
"Restrict by an asset characteristic (PII, project, sensitivity) that crosses connections"	Purpose (tag-scoped), or a rule-based persona	Only if domains don't already separate it, and only when your tagging is mature and governed.
"Organize or assign ownership of assets by business unit"	Domain + owner/steward fields	An organizational container, not access control. A persona can be scoped to a domain for visibility.
"Who approves changes or access requests"	Governance workflow	Solves the "everyone with edit access gets the request" mess. Keep it to 2–3 approval levels.
"Map corporate groups to access automatically"	Groups + SSO/SCIM	Manage access through groups, not individuals.
"A bespoke role beyond the base roles"	Sub-role	True custom roles are rare; a scoped persona plus a sub-role usually suffices.

Three distinctions that resolve most confusion

• Access is three layers, and each answers a different question. License tier / base role (what class of user), group or SSO membership (which org population), and persona (what they can see and do in the catalog). The most common design mistake is conflating groups with personas: groups are user-management buckets that populate persona membership; the persona defines the actual access. Design the layers separately.

• Separate "what you can SEE" from "what you can DO." Visibility follows the persona a user has selected; the actions available to them are evaluated across all of their personas and purposes, with the highest applicable permission winning and any deny overriding it. This is why a user can sometimes edit an asset that isn't in their currently selected persona—it's working as designed. It helps to keep three read/edit states in mind: by default a user has implicit ("bootstrap") read on assets, which typically shows as a lock icon and is read-only in the UI; a persona or connection grant turns that into explicit read (the lock clears, but it's still read-only); and an update permission or a workflow-approved change is what actually enables editing. A connection admin is a separate source of access—that status grants full metadata access to every asset in that connection, independent of any persona. Confirm the exact permission-evaluation, read-state, and policy-type semantics in the Atlan product documentation before relying on edge-case behavior.

• Atlan governs access; it doesn't grant it at the source. Atlan is your discovery layer and an access-request broker: it can't directly modify Snowflake or warehouse grants. Design for the hybrid model: SSO groups for base access + an Atlan request workflow for incremental access + a backend process in your own environment that executes the actual grant.

Domains vs personas. Domains express ownership and organization; personas express access. A shared asset (for example, a dimension table) can appear in multiple domains: this is expected. Use a domain-scoped persona when you need business-unit visibility segregation. Domain policy management is a privileged governance/administration sub-role capability, not something you achieve by scoping a separate persona—confirm the exact sub-role name and the scope it requires in the Atlan product documentation.

Sensitive data (PII / PHI / CDE): pick the vehicle by intent:

• To restrict or mask → apply an Atlan tag on the source asset, then drive masking with a data policy (purpose) scoped to that tag.
• To label or group without masking → custom metadata with an enumerated (options) property fits better than a purpose.
• To define, document, or route change approval → glossary terms plus custom metadata fields; manage change through a governance workflow.

Recommended sequence

Never design the full RBAC matrix before anyone is onboarded—that's the fastest route to setup paralysis.

1. Start with two personas, not a matrix: an admin/contributor persona and a business-user/viewer persona. Add domain- or asset-scoped personas only when you hit a concrete restriction requirement. Capture roles like data-engineer, steward, and owner as metadata fields on assets and domains, not as individual personas.
2. Enrich and curate assets first, then configure access, then roll out. Build or curate the assets → configure the two personas → smoke-test with a real test user who switches into the persona and verifies see/do behavior → enable governance workflows (Read plus a workflow before broad Update) → broaden.
3. Design personas in Atlan first, then provision IdP/AD groups to match: not the reverse. Pre-existing IdP groups are often the wrong granularity for the catalog. Confirm your identity team has SSO configuration in flight, but don't constrain persona design to today's groups. Manage access through groups with predictable naming conventions (for example, ATL_Finance_Analysts_ReadOnly) so default persona selection and audits stay sane. Map only your access groups to the IdP: separate access/permission groups (few, broad) from ownership or notification groups (many, narrow), and sync just the former; syncing every org group creates unmanageable sprawl.
4. Decide SSO/SCIM early, but don't block initial onboarding on it. Onboard a small pilot manually and layer SSO once configured. Surface SCIM setup as a long-lead item—broken or incomplete provisioning silently blocks broad rollout.
5. Start long-lead approvals at kickoff. Security review, SCIM provisioning, and any AI-feature legal or architecture approval can run for months and silently block go-live. Raise them as early actions with a named owner and a date, not afterthoughts.

For sensitive-data and AI classification at scale: tag the source asset, propagate the classification along lineage or hierarchy to downstream assets, and drive masking from a data policy on the tag. For inconsistent or cryptic column names where manual tagging won't scale, automate with rule-based tagging or AI classification—and begin the security-approval process now, since it runs on a multi-month lead. Scope who can run enrichment via a persona, and enrich your most-visited assets first rather than the entire estate.

Governance workflow design:

• Pick the template to the job: change management (metadata updates), new entity creation (new data products, glossaries, terms, tags), access management (provision/revoke), or policy approval.
• Keep the approval chain to 2–3 levels: data owner first, then a governance or standards team. Autoapprove low-risk changes and requests from owners; require manual approval for anything touching CDEs, PII, policies, or cross-domain assets.
• Keep forms short: 3–5 key fields.
• Avoid an all-admins fallback approver group: it produces notification storms and dead workflows. Scope the fallback narrowly.
• Monitor request health and keep an inbox etiquette of responding quickly; enable Slack/Teams notifications. Branch by metadata attribute (domain, tag, certificate) when one workflow must route different paths.

Common pitfalls

• Designing a full horizontal/vertical RBAC matrix as individual personas before onboarding anyone → paralysis. Those distinctions are metadata fields.
• One persona per connector or per data source → unmanageable sprawl. A persona is role-scoped and spans many connections.
• Reaching for purposes, deny, or custom roles when a simple persona tier works.
• Promising Atlan directly writes source grants → it brokers the request; your backend executes the grant.
• Enabling broad Update before Read plus a governance workflow is smoke-tested.
• Treating the "show all assets" browsing control as a security control → it's a UX control, not a security boundary; confirm what actually restricts backend reads in the product reference.
• Too many approval levels, or an all-admins fallback approver → unanswered requests and dead workflows.
• Deferring security, SCIM, or AI-legal approvals until go-live → a silent multi-month blocker.
• Duplicating the same glossary policy across every persona → use one dedicated glossary-access persona assigned to the relevant groups instead.

Troubleshooting

Access always comes from one of four sources—check all four, not just the selected persona: (1) persona policies, (2) connection-admin status, (3) hard-coded bootstrap policies, and (4) governance workflows (which override everything, including admins).

Symptom	Likely cause	Next move
Sees a term but no assets	Only bootstrap glossary read	Add both a glossary policy and a metadata policy
Asset shows a lock icon but is visible	Implicit (bootstrap) read only	Add explicit read via a persona or connection; wait out a short sync window
Can't edit despite being an admin	An active governance workflow	Submit the change through the workflow; check its coverage and approvers
Can edit an asset not in the selected persona	Permissions evaluate across all sources	Working as designed—the right comes from another persona, connection-admin, or bootstrap
A deny "isn't working"	Deny may also remove read; the rule may not match	Confirm the deny saved and that the rule expression actually matches
Removed from a persona but still has access	Another access source	Check connection-admin status, bootstrap read, other personas, and the base role
Can't find a schema when browsing	Very large schema list	Use rule-based selection or a qualified-name expression, or grant at the database level
Guest/consumer edits "don't work"	No workflow to route suggestions	Enable a change-management workflow so guests can suggest changes
Workflow notifications not firing	Notification/integration config	Verify Slack/Teams notification setup and the approver group

Diagnostic order when a user "can't do something": confirm their base role → check whether they're a connection admin anywhere → list their personas (look for a deny) → check whether governance workflows are enabled → check for deny policies. Persona and policy changes take a short time to sync—refresh before assuming a misconfiguration.

"A user isn't in the group." The most common cause is sync lag, not misconfiguration. If a user was granted an IdP role after the last sync, they won't appear until the next cycle. Verify an exact role-name match, check the Atlan group's member list, and wait a full cycle before escalating. Persistent provisioning issues (memberships not persisting, SCIM linking errors, per-group license-tier needs) are worth capturing with the exact error and raising with Atlan support.

Legacy users have the wrong roles after group-based role mapping is introduced. Group-role automation typically acts on users as they enter a group—users who predate the mapping keep whatever role they had. The clean one-time fix: reset the affected population's roles to the lowest tier, then re-run the group-role workflow so everyone inherits the correct role from their group membership.

Persona-shaped landing experience. Persona assignment alone doesn't force what a user lands on: if the tenant-wide "show all assets" browsing control is left on, users can switch out of their persona view. Decide deliberately whether personas are the source of truth for browsing, and configure the tenant accordingly. A domain filter inside a persona requires a domain policy on that persona—by design, so add a minimal read-the-relevant-domains policy where you want domain filtering to work. If you want a specific persona to be the default view, persona ordering can influence it (some tenants order personas alphabetically, so a numeric prefix like 1 - BI Analysts can help): confirm current default-selection behavior in the product reference. Remember the "show all assets" browsing control is a UX control, not a security boundary (see the pitfall described earlier).

Sample data access can be gated at more than one layer. A connection-level setting controls whether sample-data preview is available at all; viewing sample data requires a data/query policy on the user's persona for that connection; and uploading sample files requires an asset-level update permission. When "sample data doesn't show," check each of these layers rather than only the persona—confirm the exact settings and policy types for sample-data access in the product reference before troubleshooting. Also note a scoping subtlety: purposes are scoped by tag; if you need distinct treatment per tag value, use rule-based persona selection on tag values, or model each value that needs separate treatment as its own tag—confirm current tag-value scoping behavior in the product reference. And for zero-tolerance PII, mask or replace values before ingestion in your own environment—the platform doesn't transform data at ingest.

Single access plane over Snowflake/AD. Atlan can't be your only access-control plane directly. Separate the two problems: route data-query and sample-data authentication back to the source (so each user authenticates with their own credentials and source RBAC is preserved), and route access requests through a governance workflow that fires a webhook or ticket for your environment to execute the grant. Be explicit about the audit-trail boundary—Atlan logs the approval event; what the downstream webhook does is tracked in your own systems.

Governing AI itself. As AI systems multiply, the catalog is a natural registry for them: catalog AI applications, models, and agents (including shadow AI you discover), track data lineage into AI systems, and run a unified AI-model intake through a governance workflow—conditional forms and external approvers make it workable for review boards. Framing the catalog as the governance entry point that supplies trusted context to downstream AI and copilot tools tends to gain broader internal buy-in than governance pursued for its own sake.

Post-merger or multi-entity isolation. Sequence it and never reorder: align classification, policies, and glossary standards across the merged entity first; assess technical feasibility second; design access for the merged catalog third (enforce company-level separation via connection-level scoping plus personas). Test that a deny policy actually trumps admin before designing isolation around it—the behavior is non-obvious. Confirm exact capabilities against the product reference.

Related

• Glossary, taxonomy, and metrics: for glossary-level access boundaries and term governance.
• Metadata enrichment: for scoping who can run enrichment and governing AI-generated metadata.
• Product reference: role and permission semantics, policy types, SSO/SCIM configuration, and connector access requirements.