## Purposes URL: https://docs.atlan.com/product/capabilities/governance/access-control/concepts/what-are-purposes > Purposes in Atlan scope access by asset tag so every asset marked as PII, confidential, or any sensitivity label gets the same policies applied automatically. # 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. 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 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 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 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. PII tag CO customer_orders UE user_emails CC credit_cards covered by PII Purpose 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](https://docs.atlan.com/llms/governance/access-control/add-and-manage-users/llms.txt). - **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 Create a purpose, pick its tags, and attach metadata and data policies. Add or remove the tags that decide which assets the purpose covers. Use the Metadata Policy Helper app to target assets by pattern. Reuse an existing policy without rebuilding it. Remove a user's ability to query or preview an asset's data. ## See also - [What are tags?](https://docs.atlan.com/llms/governance/tags/what-are-tags/llms.txt): The building blocks a purpose needs. - [Personas](https://docs.atlan.com/llms/governance/access-control/what-are-personas/llms.txt): The team-based complement to purposes. - [Permissions & data access](https://docs.atlan.com/llms/governance/access-control/permissions-and-data-access/llms.txt): Compare personas and purposes, and see how access layers combine. ---