Purposes
A purpose scopes access by asset tag instead of by team. Pick one or more tags, attach policies, and Atlan automatically applies those policies to every asset in the catalog that carries any of those tags, now and in the future. This makes purposes the right tool for sensitivity-driven access: a PII tag on a column is enough to trigger masking, a Confidential tag on a table is enough to restrict querying.
Why use purposes
Purposes protect a class of data by tag, so the rule follows the data instead of the team.
Tag-driven scope
Any asset that gets tagged is covered automatically. No manual list to maintain.
- Scope by PII, Confidential, or any tag
- One purpose can span many connections
- No need to list assets individually
Covers new assets
New assets inherit the policy as soon as someone tags them. No manual updates needed.
- Tag a new column and it's protected immediately
- Coverage follows the data, not a static list
- Nothing slips through between reviews
Cross-team control
Applies regardless of which persona or team the user belongs to. A deny on PII wins over every grant.
- One rule spans every team
- Explicit denies override persona grants
- Applies even to connection admins
Masking support
Instead of a full deny, mask sensitive column values so analysts see *** instead of the raw data.
- Show masked values instead of blocking the asset
- Let analysts work without exposing raw PII
- Choose a masking type per data policy
Reach for a purpose when you want the same rules to apply to all PII, confidential, or sensitive assets regardless of who owns them, when new assets should inherit those rules as soon as they are tagged, when you want to mask values for analysts who can see an asset but not its raw data, or when you want to block an action across a whole class of assets.
How purposes work
Pick the tags that define the scope, attach policies, and every asset carrying those tags is covered automatically.
Deny query on PII columns
Mask data for non-data-owners
Block metadata edits
Result: Every asset tagged PII is covered by these policies, including future assets. Tag a new column as PII and it's protected immediately.
A user covered by a purpose with a deny is denied even if a persona grants access. Denies from purposes always win over grants from personas.
How access policies combine
Access in Atlan is decided by three layers that stack on top of each other:
- Role (Admin, Member, Guest) sets the ceiling on what actions are possible at all. See Assign roles.
- Personas scope access by team, and purposes scope access by asset tag. A user's grants are the union of everything their personas and purposes allow.
- Connection admins automatically get full metadata and data access on assets from the connections they manage.
One rule overrides everything else: an explicit deny is a hard ceiling. A deny in any metadata or data policy wins over every grant, including the Admin role, Connection Admin status, and allow grants from any other persona or purpose. Approval workflows add grants but cannot lift a deny.
| Scenario | Result |
|---|---|
| Admin role + explicit deny | Blocked. Deny overrides Admin role. |
| Persona A (read-only) + Persona B (full access) | Full access. Grants are combined. |
| Persona (allow) + Purpose (explicit deny) | Blocked. Deny wins across all layers. |
| Persona (read-only) + Purpose (full access on tagged assets) | Full access on tagged assets, read-only elsewhere. |
| Connection Admin + Guest role | Can edit that connection's assets. Connection Admin lifts the Guest ceiling for that connection. |
Manage purposes
Protect data by tag
Create a purpose, pick its tags, and attach metadata and data policies.
Choose what to protect
Add or remove the tags that decide which assets the purpose covers.
Create policies for multiple assets
Use the Metadata Policy Helper app to target assets by pattern.
Copy policy to another purpose
Reuse an existing policy without rebuilding it.
Revoke data access
Remove a user's ability to query or preview an asset's data.
See also
- What are tags?: The building blocks a purpose needs.
- Personas: The team-based complement to purposes.
- Permissions & data access: Compare personas and purposes, and see how access layers combine.