✦TL;DR

Configure metadata access in personas: control who can view, edit, or restrict metadata, tags, terms, and governance properties, including deny rules that override grants from other policies.

||

Your AI can read this via Docs MCPcurl -fsSL "https://docs.atlan.com/install-docs-mcp" | bashConnect

Metadata policy

Atlan governs metadata itself: metadata policies control who can view, edit, or restrict tags, terms, certification status, and governance properties inside a persona. Metadata policies let admins implement fine-grained governance over asset metadata, custom properties, and related objects while ensuring that only authorized users can configure changes and access data quality rules.

Use metadata policies to implement fine-grained governance over metadata, ensuring consistency and compliance across your data ecosystem. Metadata policies govern access to:

• Asset metadata: names, descriptions, classifications, and custom metadata
• Tags and terms: adding, removing, and managing asset associations
• Governance properties: certification status and ownership
• API operations: programmatic access to metadata objects

Metadata policies don't govern Data Quality rules (since DQ configuration and permissions are managed separately), data access (the actual querying and retrieval of data), Connection Admin privileges (which grant automatic access to all assets within a connection), or bootstrap permissions (the role-based baseline permissions that apply outside of personas).

Access

Metadata policies aren't enabled by default. To use them, you must be an admin user with permissions to define personas and governance settings.

You can access this in Governance → Access Control → Personas, then open a persona (or create a new one), go to the Policies tab, and click New Policy → Metadata Policy. Once saved, the policy applies to all users and groups linked to that persona.

Name

Specifies a unique name to identify the metadata policy in Atlan. This name must briefly describe the purpose or scope of the policy.

Example:

Marketing-metadata-policy

Select connection

Choose the Atlan connection on which this policy is applied. All assets within the selected connection are included by default unless you narrow them down with an asset selector.

Example:

Snowflake / analytics-prod

Asset scope

Defines which assets the metadata policy applies to. By default, the scope includes all assets in the selected connection, but you can narrow this to specific databases, schemas, or individual assets.

All assets

Includes every asset within the chosen connection. Use this option when the policy must apply broadly, without restricting to specific assets.

Example:

All assets in Snowflake / analytics-prod

Add via browse

Manually refine the scope of your metadata policy by selecting only the assets you want to include. This option lets admins precisely target policies for specific teams, domains, or datasets instead of applying them broadly to an entire connection. You can combine different selection modes to cover multiple use cases.

Browse

Use the asset hierarchy to navigate through the connection, starting from databases down to schemas, tables, or columns. This is useful when you know the structure and want to visually drill down to the right assets.

Example:

Select the database `analytics_prod` → schema `sales_reporting` → table `customer_orders`.  

Search

Search directly within the connection to locate specific assets by name. This is faster when you already know the name or partial name of the asset you want to include.

Example:

Search for `customer_*` to find and add all customer-related tables in the connection.  

Custom

Define the scope using a qualified name or pattern. This gives maximum flexibility, especially in large environments where browsing or searching might not be efficient.

Example:

default/snowflake/analytics_prod/sales_reporting/*

Add via rules

Select assets dynamically by applying rules instead of choosing them one by one. This approach keeps the policy updated automatically as new assets are added that meet the defined conditions. For example, include assets tagged with PII or any schema starting with finance_.

Data Quality vs ABAC

If Data Quality (DQ) is enabled on your tenant, ABAC-driven rules won't be visible in the UI. Metadata policies (including enhanced metadata policies) don't cover DQ rules or DQ permissions.

Rules can be combined in two ways:

• Match all: the asset must satisfy every defined rule.
• Match any: the asset can satisfy one or more rules.

Each rule consists of three parts:

• Attribute: the property to filter on.
• Operator: the matching condition (equals, contains, starts with).
• Values: the specific inputs for comparison.

A maximum of 3 filters can be added for now. This pattern includes all schemas and tables within the sales_reporting schema of the analytics_prod database.

Tags
Select assets based on Atlan tags. Useful for enforcing policies on sensitive classifications such as PII, Confidential, or GDPR.

Operators:

• is one of: includes assets that contain any of the selected tag values
• isn't: excludes assets that contain the selected tag values

Example:
Grant access to assets tagged with PII:

• Attribute: Tags
• Operator: is one of
• Value: PII

Result: Assets with the PII tag are included in the policy.

Schema qualified name
Select assets based on their schema qualified names. Enables rules scoped to specific schemas or to exclude irrelevant ones.

Operators:

• equals: matches assets with the exact schema qualified name
• isn't: excludes assets with the specified schema qualified name
• starts with: includes schemas whose qualified name begins with the specified string
• ends with: includes schemas whose qualified name ends with the specified string

Example:
Exclude the bronze schema from a policy:

• Attribute: Schema qualified name
• Operator: isn't
• Value: bronze

Result: Assets in the bronze schema are excluded, while other schemas remain included.

Database qualified name
Select assets at the database level using their qualified names. Useful for granting access to large logical groups of assets or excluding noisy databases.

Operators:

• equals: matches the exact database qualified name
• isn't: excludes assets from the specified database
• starts with: includes databases whose qualified names begin with the specified string
• ends with: includes databases whose qualified names end with the specified string

Example:
Include only databases starting with finance_:

• Attribute: Database qualified name
• Operator: starts with
• Value: finance_

Result: Assets in databases prefixed with finance_ are included in the policy.

Properties → Name
Select assets based on their display or technical name. Useful for targeting assets that follow naming conventions.

Operators:

• equals: matches assets with the exact name
• isn't: excludes assets with the specified name
• starts with: includes assets whose names begin with the specified string
• ends with: includes assets whose names end with the specified string

Example:
Include assets whose names end with orders:

• Attribute: Properties → Name
• Operator: ends with
• Value: orders

Result: Assets with names like customer_orders or daily_orders are included.

Domain and asset type rules

Two rule attributes scope a metadata policy by how assets are organized rather than by where they live: Domain and Asset type. Both are available for every tenant.

To use them, open a persona, go to Policies, add or edit a metadata policy, choose Add via rules, and select Domain or Asset type as the attribute for a rule. Both attributes support the same operators:

Attribute	What it matches	Operators
Domain	Assets assigned to one or more domains	Is one of, Is not
Asset type	Assets of one or more types, for example Table, View, or Column	Is one of, Is not

The asset types you can choose depend on the connection selected for the policy. If the policy isn't tied to a connection, all asset types are listed.

Example: Give the Marketing team's persona access to every asset in the Marketing domain:

• Attribute: Domain
• Operator: Is one of
• Value: Marketing

Result: Every asset assigned to the Marketing domain is in scope. Assets you assign to the Marketing domain later are covered automatically, without editing the policy.

Rules match only assets where the attribute is set

A Domain or Asset type rule using Is one of matches only assets that have that attribute set explicitly:

• Assets with no domain assigned aren't matched by a Domain rule.
• Rules don't propagate from parent to child. If a table is assigned to the Marketing domain, the table is covered but its columns aren't, unless you assign the domain to the columns as well.
• Is not works the other way around: it matches every asset in scope that doesn't have the selected value, including assets with no domain assigned.

Before you rely on a rule, confirm that the domain is assigned to every asset you want the policy to cover.

Combine Domain and asset type rules

How rules combine depends on where you set them:

• Within one policy, you choose Match all (an asset must satisfy every rule) or Match any (an asset must satisfy at least one).
• Across policies in a persona, access is a union (OR). An asset is accessible if any policy that grants access covers it, so adding a policy never narrows what the persona can already see. Deny policies are the exception: they exclude the assets they match.

A Domain rule in one policy next to an Asset type rule in another therefore widens access instead of narrowing it.

Example: A persona has two metadata policies:

• Policy 1: Domain is one of Marketing
• Policy 2: Asset type is one of Table

Result: Users get access to all assets in the Marketing domain, and to every table, including tables outside the Marketing domain. They don't get only Marketing tables. To limit access to Marketing tables, put both rules in a single policy and combine them with Match all.

AI asset types

AI assets (AI applications, AI models, and AI model versions) are authorized through AI policies, which grant access by asset type only. They don't read Domain or Asset type rules from a metadata policy. An AI policy gives access to every asset of the types it lists, regardless of domain, even if the same persona also has Domain rules. To control access to AI assets, scope the AI policy itself.

Dynamic metadata policies

A standard metadata policy is scoped to a single connection: you pick a connection first, and rules can only narrow assets within it. Covering a domain that spans several sources, for example Tableau dashboards, Power BI reports, and SQL tables, means one policy per connection, which leads to persona sprawl and constant manual upkeep as new data lands.

A dynamic metadata policy removes the connection requirement. You define a metadata rule, and every asset that matches is in scope regardless of which connection it belongs to. New assets that match the rule are covered automatically as they're ingested, so access doesn't lag behind new data.

Preview feature enabled through Labs

Dynamic metadata policies are a preview capability. The Dynamic Metadata Policy option appears in New Policy only after an admin enables the Labs toggle Allow dynamic policies in personas. For the step-by-step flow, including enabling the toggle, see Create a dynamic metadata policy.

Connection-scoped vs. dynamic

	Standard metadata policy	Dynamic metadata policy
Connection	Required—you select one connection	Not selected—the rule defines the scope
Coverage	Assets within the chosen connection	Assets across every connection that match the rule
New assets	Covered only if they fall under the selected connection and asset selector	Covered automatically when they match the rule
Typical use	Fine-grained control within one source	One persona covering a domain that spans many sources

Rule attributes

A dynamic metadata policy is defined entirely by its rule. As with connection-scoped rules, you can combine up to 3 rules using Match all (an asset must satisfy every rule) or Match any (an asset must satisfy at least one rule). Each rule has an attribute, an operator, and one or more values.

Supported attributes include:

• Domains: select assets that belong to one or more domains. This is the most common way to grant a persona access to everything in a domain across all sources.
• Tags: select assets by Atlan tag, for example PII or Confidential.
• Schema, database, and asset qualified name: select assets by qualified name using equals, isn't, starts with, or ends with.
• Properties → Name: select assets by display or technical name.

The operators for each attribute match those documented under Add via rules. For Domain rules, see also Domain and asset type rules.

Verify attribute availability on your tenant

The set of attributes available for dynamic policies is still expanding while the feature is in preview. Confirm what's available on your tenant before you design a policy around a specific attribute.

For the current constraints, including behavior when Data Quality is enabled and the lack of SDK or API support, see Current limitations.

Configure permissions

Define the level of control that personas have over metadata. Permissions can be combined to give broad or fine-grained access.

Assets
Controls access to the core metadata of an asset.

• Read: view metadata such as names, descriptions, and lineage.
• Update: edit metadata fields like descriptions, owners, and classifications.
• Governance: manage governance properties, including certification status and ownership.

Update custom metadata values
Lets you edit custom metadata structures applied to assets.

Example:
A data administrator updates the "Data Quality SLA" field in a custom metadata template.

Add tags / Remove tags
Manage Atlan tags on assets. Tags can represent sensitivity (PII), compliance (GDPR), or business-specific categories.

Example:

• Add the tag PII to a table.
• Remove the tag Deprecated from a dataset.

Add terms / Remove terms
Control glossary term associations on assets. Terms link business definitions to technical assets.

Example:

• Add the glossary term Customer to a table.
• Remove the glossary term Revenue from a column.

API
Permissions for programmatic access through the Atlan API.

• Create: create new metadata objects through API requests.
• Delete: delete metadata objects through API requests.

Example:
Use API automation to create a new asset or remove deprecated objects.

Deny selected permissions

Explicitly restricts certain actions, even if they're granted through another policy. Deny rules take precedence and override grants from other metadata or data policies. Deny rules have significant impact on asset visibility and access:

• Single persona with deny: Asset appears with a locked icon; denied permissions are blocked but the asset isn't removed from search results
• Same persona with both grant & deny: Deny takes precedence; asset appears with a locked icon, as described in the previous scenario
• Different personas with conflicting permissions: Deny still takes precedence; asset appears with locked icon in all-assets view and can't be edited

Visibility depends on the "All assets" workspace setting

The locked-icon behavior in the third scenario requires the workspace's View "All assets" in Assets Discovery Labs setting to be On (the default). If that setting is off, users see only what their personas cover; a denied user may not see the locked asset at all, because no persona grants visibility to begin with.

Asset visibility decision matrix

Scenario	Persona A	Persona B	Asset Visibility	User Experience
Single persona, deny only	Deny	N/A	Locked	Asset visible with locked icon, can't edit
Single persona, grant + deny	Grant + Deny	N/A	Locked	Asset visible with locked icon, can't edit (deny wins)
Multiple personas, conflicting	Grant	Deny	Locked	Asset visible with locked icon, can't edit
Multiple personas, no deny	Grant	Grant	Visible	Asset visible and editable