====== Row-Level Filters ======
**Row-level filters** represent a fine-grained access control mechanism within **Unity Catalog** that restricts data access at the individual row level based on user attributes, organizational context, or defined conditions. This approach enables consistent enforcement of data access policies across multiple tools and platforms, including data transformation frameworks, business intelligence applications, and analytics notebooks, creating a unified security posture for sensitive data governance.

===== Overview and Purpose =====
Row-level filters address a critical challenge in modern data platforms: the need to provide users with access to shared datasets while simultaneously restricting visibility to rows that match their organizational role, geographic region, department, or other contextual attributes. Rather than requiring separate copies of datasets or complex manual access management, row-level filters apply security policies at query execution time, ensuring that users only retrieve data they are authorized to access (([[https://docs.databricks.com/en/user-guide/security/unity-catalog/row-level-filters.html|Databricks Documentation - Unity Catalog Row-Level Filters (2026]])).

This mechanism is particularly valuable in multi-tenant environments, enterprises with complex organizational hierarchies, and scenarios involving sensitive personally identifiable information (PII) or regulated data. By enforcing access controls consistently across the data platform—whether users query through SQL, dbt, dashboards, or Python notebooks—row-level filters eliminate gaps in security enforcement that can arise from tool-specific or manual access management approaches.

===== Technical Implementation =====
Row-level filters operate as declarative security policies that are evaluated during query execution within the data catalog layer. The filters function by evaluating a Boolean expression against each row in a table, determining whether the current user should have access to that specific row based on user attributes and filter conditions (([[https://docs.databricks.com/en/user-guide/security/unity-catalog/row-level-filters.html|Databricks - Unity Catalog Security Features (2026]])).

The implementation typically involves:

  * **Attribute-based evaluation**: The system evaluates user properties—such as department, region, team identifier, or custom user attributes—against row-level predicates stored in the catalog.
  * **Dynamic query transformation**: When a user executes a query, the database optimizer automatically injects filtering conditions that restrict returned rows based on the user's attributes.
  * **Consistent enforcement**: The filters apply uniformly across all query interfaces and tools that connect to Unity Catalog, preventing users from circumventing access controls by switching between interfaces.

The filtering expressions support standard SQL predicates and can reference both user context (through built-in functions like `current_user()` or custom user attributes) and column values in the target table. This approach maintains the semantics of the underlying query while transparently restricting results.

===== Integration Across Data Platforms =====
A key strength of row-level filters within Unity Catalog is their ability to enforce consistent access policies across diverse tools and workflows. Organizations deploying dbt for transformation, Tableau or Looker for business intelligence, and Jupyter notebooks for exploratory analysis can apply the same row-level security policies universally (([[https://www.databricks.com/blog/open-platform-unified-pipelines-why-dbt-databricks-accelerating|Databricks - Open Platform and Unified Pipelines (2026]])).

When a dbt model queries a table with row-level filters, the filters are applied to all downstream transformations, ensuring that intermediate datasets also respect access restrictions. BI tools accessing the same tables automatically enforce the filters without requiring separate dashboard-level security rules. This integration eliminates manual duplication of access control logic across platforms and reduces the risk of inconsistent enforcement.

===== Use Cases and Applications =====
Row-level filters enable several important data governance scenarios:

  * **Sales and customer data**: Restrict sales representatives to view only records for their assigned accounts, regions, or customers.
  * **Financial reporting**: Limit access to cost or revenue data based on the user's business unit or approval level.
  * **Healthcare and PII protection**: Ensure patients see only their own medical records, and providers access only relevant patient cohorts.
  * **Regulatory compliance**: Implement data residency and access restrictions required by GDPR, HIPAA, or industry-specific regulations.

===== Challenges and Considerations =====
Despite their utility, row-level filters present operational and technical challenges. Managing complex filter expressions across many tables requires careful design to prevent unintended access restrictions or performance degradation. Performance can be affected if filters require expensive computations or table scans, particularly in high-scale environments with large numbers of users and tables. Additionally, organizations must maintain clear documentation of which filters apply to which tables and ensure that user attributes are accurately maintained in the identity system (([[https://docs.databricks.com/en/user-guide/security/unity-catalog/index.html|Databricks - Unity Catalog Security Framework (2026]])).

Debugging access issues can be complex when multiple filters apply across a query execution path, and auditing access patterns requires integration with comprehensive logging systems.

===== Current Status in Data Platforms =====
Row-level filters have become a standard feature in modern cloud data platforms, including Databricks Unity Catalog, Snowflake, and BigQuery. They represent an evolution from coarser-grained table-level access controls, enabling organizations to share data more granularly while maintaining security boundaries. As data volumes grow and regulatory requirements become more stringent, row-level filtering has transitioned from an optional feature to an essential capability for enterprise data governance.

===== See Also =====

  * [[column_masks|Column Masks]]
  * [[attribute_based_access_control|Attribute-Based Access Control (ABAC)]]
  * [[column_level_data_lineage|Column-Level Data Lineage]]

===== References =====