Hi @r_w_,
Appreciate you sharing the details. the "User Access" column in the data classification results view is one of those features that is not thoroughly covered in the public documentation yet, so I understand the confusion. Here is what I have found.
WHAT THE "USER ACCESS" COLUMN SHOWS
The "User Access" column is designed to display the number of distinct users who accessed the classified table within the past 7 days. It provides a quick risk signal: if a table contains sensitive data (as identified by classification) AND many users are accessing it, that is a higher-priority item for governance action such as applying ABAC policies.
WHY IT MAY REMAIN BLANK
There are a few reasons this column can stay empty even after you run SELECT queries:
1. System tables must be enabled and accessible. The "User Access" metric is derived from system tables, specifically the access-related system tables like system.access.audit (audit logs) and/or system.access.table_lineage (lineage tracking). If these system tables are not enabled or accessible in your account, the classification results view has no access data to display.
To check if system tables are available, try running:
SELECT * FROM system.access.audit LIMIT 10;
If this returns an error about the table not existing or insufficient permissions, system tables may not be enabled, or you need access granted by your account admin.
2. There is a data pipeline delay. Even with system tables enabled, data does not flow instantaneously. Audit log and lineage data can take up to 24-48 hours to appear in system tables after the events occur. The classification results view then needs to aggregate this data, which adds additional processing time.
3. Serverless compute is required. The data classification feature requires serverless compute to be enabled in your workspace. Without it, some features of the results view may not fully populate.
4. Permissions matter. You need appropriate permissions on the system tables for the dashboard to pull access data. Specifically, you need USE CATALOG and USE SCHEMA on the system catalog, plus SELECT on the relevant system tables. Account admins have this by default, but other users need explicit grants.
STEP-BY-STEP TROUBLESHOOTING
Step 1: Verify system tables are enabled at the account level. Your account admin can check this. The system catalog is included in every Unity Catalog metastore, but the metastore needs to be on Unity Catalog Privilege Model Version 1.0 or higher to access system tables. You also need at least one Unity Catalog-enabled workspace in your account.
Step 2: Confirm you can query the system tables directly. Try these queries:
-- Check if audit logs are available
SELECT * FROM system.access.audit
WHERE action_name = 'commandSubmit'
LIMIT 10;
-- Check if table lineage is available
SELECT * FROM system.access.table_lineage
WHERE target_table_full_name = 'your_catalog.your_schema.your_table'
OR source_table_full_name = 'your_catalog.your_schema.your_table'
LIMIT 10;
If these return results, the data exists and the classification results view should eventually pick it up.
Step 3: Wait for the aggregation cycle. After enabling system tables (if they were not already), give it 48-72 hours for the pipeline to backfill data and for the classification results to refresh their aggregated metrics.
Step 4: Verify your queries are being captured. Queries run from a SQL warehouse or serverless compute should appear in audit logs and lineage tables.
BUILD YOUR OWN USER ACCESS QUERY
If you want to verify the data independently while waiting for the results view to populate, you can query the system tables directly. For example, using the table lineage system table:
SELECT
source_table_full_name AS table_name,
COUNT(DISTINCT created_by) AS user_access_count
FROM system.access.table_lineage
WHERE source_table_full_name = 'your_catalog.your_schema.your_table'
AND event_time >= current_timestamp() - INTERVAL 7 DAYS
GROUP BY source_table_full_name;
You can also check the data classification results system table directly to confirm your tables were classified:
SELECT *
FROM system.data_classification.results
WHERE catalog_name = 'your_catalog'
LIMIT 20;
Note: The data_classification.results table is accessible only to account admins by default, so you may need explicit grants if you are not an account admin.
REGARDING YOUR ABAC POLICIES
Applying ABAC policies should not affect whether the "User Access" column populates. ABAC controls who can see what data at query time, but it does not change how access events are recorded in system tables. The classification results view should reflect access attempts regardless of ABAC policies being in place.
RELEVANT DOCUMENTATION
- Data classification overview: https://docs.databricks.com/en/data-governance/unity-catalog/data-classification.html
- System tables reference: https://docs.databricks.com/en/admin/system-tables/index.html
- Audit log system table: https://docs.databricks.com/en/admin/system-tables/audit-logs.html
- Table lineage system table: https://docs.databricks.com/en/admin/system-tables/lineage.html
- Data classification results system table: https://docs.databricks.com/en/admin/system-tables/data-classification.html
- ABAC (attribute-based access control): https://docs.databricks.com/en/data-governance/unity-catalog/abac/index.html
SUMMARY
The most likely reason the "User Access" column is blank is that the system tables (audit logs and/or table lineage) are not enabled or accessible for your account, or the data has not had enough time to propagate. Verify system tables are enabled, ensure you have the right permissions, wait a couple of days, and the column should begin populating.
If it still remains blank after confirming all of the above, I would recommend opening a support ticket with Databricks referencing the data classification feature (Public Preview), as the team can investigate whether the User Access aggregation is working as expected for your specific setup.
Hope this helps!
* This reply used an agent system I built to research and draft this response based on the wide set of documentation I have available and previous memory. I personally review the draft for any obvious issues and for monitoring system reliability and update it when I detect any drift, but there is still a small chance that something is inaccurate, especially if you are experimenting with brand new features.
