## Permissions & data access URL: https://docs.atlan.com/product/capabilities/governance/access-control/permissions-and-data-access > Control what users can see and do in Atlan once they have signed in. Scope access by team with personas, by data sensitivity with purposes, by connection, or hide assets entirely. Learn which control to use and how role, persona, and purpose combine. # Permissions & data access Once users are in your workspace, permissions control what they can see and do. Atlan layers a few mechanisms, and which one you reach for depends on what you are scoping: access by **team**, by **data sensitivity**, by **connection**, or hiding specific assets entirely. Your platform [role](https://docs.atlan.com/llms/governance/access-control/add-and-manage-users/llms.txt) sets the ceiling on what is possible at all. **Personas** and **purposes** then scope that access to the right assets. The sections below help you pick the right control. ## Which control to use Bundle users and groups with policies and a curated catalog view. Use when different teams need to see different parts of the catalog. Apply policies to every asset carrying a tag such as PII, across all teams. Use for sensitivity-driven rules and column masking. Control who can administer a connection and which credentials users query with. Use when query access depends on credentials. Hide specific assets or glossaries from users who shouldn't see them. Use to keep a least-privilege catalog. ## Personas or purposes? The two main controls scope access along different dimensions, and most teams use both together: Use a persona when… Access depends on **who the user is**. You want a team to see a curated slice of the catalog and land on a tailored view. Scope team access Use a purpose when… Access depends on **how assets are tagged**. You want the same rule to apply to every PII or confidential asset, no matter which team owns it. Protect sensitive data ## How layers combine Role, persona, and purpose stack. Your platform role sets the ceiling, personas and purposes add scoped grants (a user gets the **union** of all their grants), and an **explicit deny in any policy overrides every grant**, including the Admin role. For the full evaluation order and the "which wins" table, see [how access policies combine](https://docs.atlan.com/llms/governance/access-control/what-are-purposes/llms.txt). ---