Personas
A persona scopes what a team sees and can do in Atlan. It bundles the users and groups on a team, the policies that govern what they can access, and the display preferences that shape their view of the catalog. Every member of a persona inherits its access and view automatically, so a data engineering team sees only the assets relevant to their work while a finance team sees only finance data.
Why use personas
Personas give each team a focused, consistent view of the catalog without editing access user by user.
Team-scoped
Each team sees only the assets relevant to their work, not the entire catalog.
- Give each team its own slice of the catalog
- Hide connections or domains a team doesn't need
- Stop a team from querying sources outside its scope
Policies in one place
Bundle metadata, data, business graph, and domain policies and apply them to everyone at once.
- Metadata policies for what they can edit
- Data policies for what they can query
- Business graph and domain policies for lineage and ownership
Tailored view
Set the landing page, visible asset types, sidebar tabs, and discovery filters per team.
- Land each team on a relevant home page
- Show only the asset types and filters they use
- Hide sidebar tabs that don't apply
Automatic inheritance
Add a user or group and they inherit the persona's access and view immediately.
- Add a group to onboard a whole team at once
- New hires get access on day one
- Remove someone and access is revoked on next sign-in
Reach for a persona when different teams should see different subsets of the catalog, when a team should land on a filtered view on sign-in, when you want to stop a team from querying specific connections, or when external stakeholders need a curated, read-only experience.
How personas work
You create a persona, add the users and groups who belong to it, and attach the policies that define what they can access. Everyone you add inherits those policies automatically. A persona's scope only hides assets once you turn off the see-everything default, so pair personas with restrict asset visibility to limit what a team can browse.
Metadata policy: read marketing assets
Data policy: query marketing data
View: lands on the Marketing dashboard
Result: Sarah, Tom, and everyone in the Marketing Analysts group inherit the persona's policies and view. Add a user or group and they get the same scoped access automatically; remove them and it's revoked on their next sign-in.
A user can belong to multiple personas at once. Their effective access is the union of all their personas' grants, with explicit denies always winning. For how personas, purposes, and roles interact, see Permissions & data access.
Manage personas
Set up team access
Create a persona that bundles users, groups, policies, and a view for a team.
Add team members
Add or remove the users and groups who inherit the persona.
Customize catalog view
Set the landing page, visible asset types, sidebar tabs, and filters a team sees.
Copy policy to another team
Reuse an existing policy in another persona without rebuilding it.
Restrict asset visibility
Turn off the see-everything default so a persona's scope actually limits what users browse.
Restrict glossary visibility
Hide glossaries from users outside the personas that should see them.
See also
- Set up team access: Build a persona, define its policies, and configure the initial settings.
- What are groups?: How groups relate to personas.
- Purposes: Tag-based access control, the complement to personas.
- Permissions & data access: Compare personas and purposes, and see how access layers combine.