Metadata policy

Metadata policies define who can view, edit, or restrict metadata in Atlan. They let admins control changes to asset details such as names, descriptions, classifications, and custom metadata. They also govern access to data quality rules, ensuring that only authorized users can configure or update them.

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.

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 is fully hidden (not visible at all)
• Same persona with both grant & deny: Deny takes precedence; asset isn't visible
• Different personas with conflicting permissions: Deny still takes precedence; asset appears with locked icon in all-assets view and can't be edited

Asset visibility decision matrix

Scenario	Persona A	Persona B	Asset Visibility	User Experience
Single persona, deny only	Deny	N/A	Hidden	Asset not visible
Single persona, grant + deny	Grant + Deny	N/A	Hidden	Asset not visible (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