Skip to main content

Assets Access Control

On any database, schema, or dashboard folder, admins can manage who can access it in Catalog using the Manage access interface:

Manage access interface for databases and schemas

Tables Access Control​

Use these steps when you need to limit which teams can see tables for a database or schema in Catalog:

  1. Navigate to your database or schema page through the left menu

    Database or schema page in the left menu

  2. Click the top right corner button Manage access

    Manage access button location

  3. Then select the teams that should have access to the data set

    Team selection for data set access

Dashboards Access Control​

Follow this flow to restrict which teams can open a dashboard folder and its contents in Catalog:

  1. Navigate to your dashboard folder page through the left menu
  2. Click the top right corner button Manage access
  3. Then select the teams that should have access to this folder and its subfolders
Dashboard folder access control

How Does It Work?​

Set the teams that should have access to the tables or dashboards in this data set or folder. Anyone who should see the data set and its tables needs to belong to at least one of those teams.

For example, any member of the HR or Sales team can access this data set's tables:

Example of HR and Sales team access to a data set
Admins and lineage visibility

Admins always see everything in Catalog, regardless of Manage access settings. Restricted assets can still appear in lineage graphs, but with limited access elsewhere in Catalog.

By default, any new data set or folder is accessible to anyone in the company. When a data set or folder access is given to only a few teams, any new asset in this perimeter inherits the access parameters.

Catalog Manage access applies to Catalog navigation, search, and asset pages. It's team-based in Catalog and doesn't replace warehouse object privileges such as Snowflake grants.

Choose Where to Restrict Access in Catalog​

Use this section when you are deciding whether to set Manage access on a database, on individual schemas, on dashboard folders, or on a combination. Start from the perimeter your teams should share, then use Hierarchical data sets interaction for how parent and child settings combine.

One Team or a Fixed Set of Teams Should Own an Entire Database​

Use: set Manage access on the database so only those teams can see any schema or table under it until you intentionally override a child data set.

New tables and schemas under that database inherit the same teams. If you need an exception for one schema, open that schema and use Manage access there. Remember that a database-level list of allowed teams still limits which schemas are visible overall, as described in Hierarchical data sets interaction and Troubleshooting visibility for asset access.

Only Certain Schemas Should Be Limited​

Use: leave the database unrestricted for company-wide discovery, or keep a wide team list on the database, then restrict individual schemas to the teams that should see those schemas.

This path fits when most of the database is public in Catalog but a few schemas need a tighter team list.

Different Teams Need Different Schemas Under the Same Database​

Use: combine a database-level configuration with schema-level Manage access so each schema lists the right teams. A child schema can add teams compared to the database, but it can't make sibling schemas visible to a team the database blocks. See Hierarchical data sets interaction and Troubleshooting visibility for asset access.

Dashboards and Subfolders Need Their Own Audience​

Use: set Manage access on the dashboard folder that should gate a branch of your BI tree. Subfolders inherit unless you override them at the child folder, the same pattern as database and schema.

Hierarchical Data Sets Interaction​

Admins can define access rights at different levels in their stack, for example at database and schema level.

Child overrides parent: A child data set or subfolder access configuration overrides its parent's.

Schema teams and database perimeter

Adding a team on a schema does not grant that team access to other schemas in the same database when the database Manage access list excludes them. The database perimeter still applies to the whole database tree. Teams you add on the child only affect assets under that child.

The behavior is the following:

  • By default a child data set, such as a schema, inherits the parent configuration. For example, if the Sales team is the only one that can see the database assets, the child schema inherits it:

    Child schema inheriting database access

  • You can then choose to modify this configuration, which overrides the database access rights. Here, all the members of the frontend team and the sales team can access the assets in the schema. They still can't browse assets in other schemas because the database-level restriction applies to the rest of the tree.

    Schema-level access override

  • You can also completely remove the inherited team from the schema access rights, which hides its assets from that team. For example:

    • The Frontend team will see the schema assets but nothing else from this database.

    • The Sales team, the only team that can see assets in this database, won't see the assets in this schema but will see all the other database assets.

      Schema access removal example

Troubleshooting​

Work through these checks in order when someone reports missing tables, schemas, or dashboard folders.

Confirm Admin Status and Team Membership​

  1. Catalog admin: Admins see every asset regardless of Manage access. Reproduce the issue using a non-admin account that matches the affected person's teams so Manage access rules apply.
  2. Team membership: The person must belong to at least one team on the asset's effective allow list. Verify teams in Teams in Catalog and provisioning in User and Team Provisioning.

Walk the Parent Chain for Tables and Schemas​

For each missing asset, open Manage access on the asset, then on its parent database when the asset is a schema or table. The effective rule is applied along the hierarchy described in Hierarchical data sets interaction.

  • Symptom: Someone is on a team listed on the schema but still can't see the schema or its tables.

  • Cause: The database Manage access list doesn't include them or any of their teams, so the database perimeter blocks the whole branch.

  • Fix: Add them to a team allowed on the database, widen the database allow list if policy allows, or restructure so the schema lives under a database with the right perimeter.

  • Symptom: Someone lost access after new tables or folders appeared.

  • Cause: New assets inherit restrictions from their parent data set or folder.

  • Fix: Adjust Manage access on the parent or child so the intended teams are included where you want inheritance to apply.

  • Symptom: Someone is on the database teams but can't see one schema.

  • Cause: The schema Manage access list removed or omitted that person's team while other schemas still list it.

  • Fix: Add the team back on the schema if they should see it, or confirm the omission is intentional.

Lineage Shows an Asset but Browse or Search Does Not​

Restricted assets can still appear in lineage graphs with limited access elsewhere, as described under Restricted Assets in Lineage in How Does It Work?. If the graph references an object they can't open from search or the left navigation, treat that as a Manage access outcome, not a missing sync.

Data Quality or Other Surfaces Look Empty​

The Data Quality Dashboard follows the same asset visibility rules as tables and schemas. If a schema or table is hidden by Manage access, its quality results won't surface for them. After you confirm integrations, see Data quality dashboard troubleshooting for tests that don't appear.

What's Next?​