Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This page provides guidance for using row filters and column masks to filter sensitive data in your tables.
What are row filters?
Row filters let you control which rows a user can access in a table based on custom logic. At query time, a row filter evaluates a condition and returns only the rows that meet it. This is commonly used to implement row-level security—for example, restricting users to records from a specific region, department, or account.
Row filters are defined as SQL user-defined functions (UDFs), and can also incorporate Python or Scala logic when wrapped in a SQL UDF. You can apply row filters per table, or centrally through ABAC policies using governed tags.
What are column masks?
Column masks control what values users see in specific columns, depending on who they are. At query time, the mask replaces each reference to a column with the result of a masking function. This allows sensitive data, such as SSNs or emails, to be redacted or transformed based on user identity or role.
Each column can have one mask. The mask is defined as a SQL UDF, and can optionally wrap Python or Scala logic, and must return a value of the same type as the column being masked. Column masks can also take other columns as inputs, for example, to vary behavior based on multiple attributes.
Like row filters, column masks can be applied per table or managed centrally through ABAC policies. They operate at query time and integrate seamlessly with standard SQL, notebooks, and dashboards.
When should you use dynamic views vs. filters and masks?
Dynamic views, row filters, and column masks all let you apply filtering or transformation logic at query time — but they differ in how they are managed, scoped, and exposed to users.
| Feature | Applies to | Managed using | Naming impact | Best used for… |
|---|---|---|---|---|
| Dynamic views | Views | SQL logic | Creates a new object name | Sharing filtered data or spanning multiple tables |
| Row filters | Tables | ABAC or mapping tables | Table name unchanged | Row-level access control tied to user or data tags |
| Column masks | Tables/columns | ABAC or mapping tables | Table name unchanged | Redacting sensitive column data based on identity |
- Use dynamic views when you need a read-only layer across one or more source tables, especially for data sharing or applying logic across multiple inputs.
- Use row filters and column masks when you want to apply logic directly to a table, without changing the table name or introducing new objects. These can be managed using either ABAC policies (recommended) or manually on tables.
For a full comparison, see Access control methods compared.
How to apply filters and masks
You can implement row filters and column masks in two main ways:
Using ABAC policies (Beta): Apply filters and masks centrally using governed tags and reusable policies. This approach scales across catalogs and schemas and reduces the need for table-by-table configuration. ABAC policies are more secure than manual table-level policies because they can be defined by higher-level admins and cannot be overridden by table owners, which helps enforce centralized access controls. They are also more performant in many cases, since filtering and masking logic in ABAC policies is evaluated more efficiently than in table-specific UDFs. Databricks recommends using ABAC for most use cases. To apply filters and mask using ABAC see Unity Catalog attribute-based access control (ABAC).
Manual assignment per table: Apply filters and masks by assigning functions directly to individual tables and columns. This method can use mapping tables or other custom logic. It allows for fine-grained, table-specific control but is harder to scale and maintain. For more information, see Manually apply row filters and column masks.