Data Access FAQ

August 14, 2026

This topic contains answers to frequently asked questions (FAQ) and some troubleshooting solutions for Data Access.

Data Access versus Data Catalog

• Are Data Access data objects the same as Data Catalog assets?

  No. Data Access data objects are different from Data Catalog assets. Data Access maintains its own separate metadata repository and ingests metadata directly from data sources instead of from Data Catalog.

• Why doesn't the ownership assigned in Data Access appear as responsibilities on the corresponding asset page in Data Catalog?

  Responsibilities in Data Catalog do not synchronize with ownership in Data Access. The two ownership models differ.

  In Data Access, ownership is inherited hierarchically, wherein the hierarchy is determined by technology (Data source > Schema > Table). In Data Catalog, ownership is determined by organizational structure (Community > Domain).

  In Data Access, if you are the owner of a schema data object, you automatically become the owner of all its child data objects, such as the tables, views, and columns within that schema. Data Catalog responsibilities do not use such hierarchical inheritance.

• Will deploying Data Access affect my Data Catalog asset count allocation?

  No. The data objects in Data Access are distinct from the assets in Data Catalog. Data Access maintains its own separate metadata repository and does not automatically populate assets in the Data Catalog. Although you can manually link a data source to an existing System Asset in the Catalog, this manual linkage does not generate new Catalog assets or consume your asset allocation.

Synchronization

• Do I need to manually synchronize a data source every time that I create or edit an access control?

  No. Whenever you create or edit an access control in Data Access, an immediate synchronization is automatically triggered. Data Access pushes your new or updated access control to the underlying data source in near real time, regardless of your synchronization schedule. However, pulling new data into Data Access, such as newly created accounts, groups, or data objects, relies on your configured synchronization schedule. Although you can trigger this inbound synchronization manually, we recommend that you let it run on its configured schedule to avoid unnecessary resource usage.

• Will an outbound synchronization from Data Access overwrite access controls that were created directly in BigQuery, and can I use locking to prevent this?

  Data Access does not automatically overwrite the native Access Control List (ACL) assignments that are made directly in BigQuery. It simply imports them during an inbound synchronization, unless you explicitly delete them from within Data Access. Data Access does not support full locking for ACL-based data sources, such as BigQuery, because the permissions and the data objects in ACL models are too deeply integrated to be separated for locking.

Access control mechanics and overlaps

• Why can't I view the list of users who have access to data in an access control?

  The list of beneficiaries is considered sensitive information. As such, you can see the beneficiaries of an access control only if you own the access control, own all the included data objects, or have the Data Access > View All Access And Usage global permission.

• Does creating a role in Data Access modify my users or groups in BigQuery?

  No. When you create a role in Data Access, it adds permissions directly to the data object in BigQuery. It does not modify the user or group objects themselves.

• How are overlapping column masks handled if a user is a beneficiary of one mask but not of the other?

  If multiple column masks apply to the same column and a user is a beneficiary of one of them, the data is unmasked for that user.

• If I have overlapping column masks with different masking methods, which masking method takes precedence?

  If multiple column masks with different masking methods apply to the same column, the most restrictive masking method takes precedence.

• If a user is a beneficiary of a row filter for a table but lacks access to that table, can the user see the filtered rows?

  No. The user needs to have access on the table with the appropriate permission, such as Read. Only then can the user see the filtered rows.

• If a user has Read permission on a table, but a row filter is created on that table and the user is not a beneficiary of any of the filter rules, will the user see any rows?

  No. The user's role-based access still allows them to run a SELECT query on the table, but the query returns zero rows because the user is not authorized for the row filter.

• If I delete an access control or remove a user from a role in Data Access, does it delete their user account in the underlying data source?

  No. Data Access manages access controls (permissions), not identities or user accounts. If you delete an access control in Data Access, the associated permissions are permanently removed from the underlying data source during the next successful synchronization. Data Access only imports accounts from your data sources; it does not create, recreate, or delete the actual user accounts within your data sources.

• Is there a risk of breaking operational processes in my data source if I accidentally delete an access control in Data Access?

  Yes. If you delete an access control in Data Access, it is removed from the underlying data source during the next successful synchronization. Use caution for access controls with high usage, just as you would if you were deleting them directly in the data source itself.

  As a safer alternative to deletion, consider deactivating the access control instead. If you deactivate an access control, it is temporarily removed from the underlying data source (during the next synchronization) but retained as an inactive draft in Data Access. This allows you to reactivate the access control if an operational process breaks. If you do choose to delete an access control, note that the deleted access control is retained in Data Access for a 48-hour window following the synchronization before it is permanently removed.

Errors

• Why do I see a "...Error 403: VPC Service Controls..." error when synchronizing my GCP or BigQuery data source?

  This error occurs because the Virtual Private Cloud (VPC) configuration of your Edge site restricts outbound traffic.

  To resolve this error, ensure that the VPC configuration allows outbound traffic to the Google API endpoints that Data Access requires.

• Why do I see a "...could not create database...Insufficient privileges to operate on account..." error when synchronizing my Snowflake data source for the first time?

  This error occurs because you have not created a configuration database and the Snowflake sync role lacks permission to create one.

  To resolve this error, run the following SQL script in your Snowflake environment, and then run the synchronization again.

  CREATE DATABASE IF NOT EXISTS COLLIBRA;

  In the script, you can replace COLLIBRA with a different database name. If you use a different name, you must also update the value in the Configuration Database field in Data Access.

• Why do I see a "This API is disabled for users without account admin status" error when synchronizing my Databricks data source?

  This error occurs because, when adding the Databricks data source to Data Access, you disabled the Account Level Access option (to enforce minimum privilege) but did not provide the Metastore Workspace Pairs. When account-level administrative access is disabled, the service principal lacks the global privileges that are required to auto-discover your metastores. If you then do not provide the Metastore Workspace Pairs, the connector tries to query the Databricks account API (list metastores) to auto-discover them, which causes this error.

  To resolve this error, provide your Metastore Workspace Pairs by mapping each metastore ID to its corresponding workspace deployment names.