---
title: "Databricks Row-Level Security"
slug: "databricks-row-level-access"
updated: 2026-03-22T17:11:20Z
published: 2026-03-22T17:11:20Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plainid.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Databricks Row-Level Security

## Row-level security (RLS)

**Row-level security (RLS)** is a fine-grained access control mechanism that restricts which rows of data a user or group can access within a table or view. In Databricks, this is commonly implemented using **Row Filters**.

Row Filters are created as **SQL user-defined functions (UDFs)** and also incorporate logic from other languages (such as Python) when wrapped in a SQL UDF.

It provides fine-grained access control by **dynamically filtering data** through conditional expressions and identity functions such as `is_account_group_member(group)`, `is_member(group)`, or other Databricks identity functions.

---

## Creating a Databricks Row Access Policy in PlainID

Note

*Ensure that your Databricks app in Orchestration is switched to Manage mode to start building your **Row-level Policy** in the Policy catalog section. See [Managing POPs](/v1/docs/managing-pops) for more information on how to change the **POP Mode**.*

Row Access Policies in PlainID can be created using the following methods:

- **Wizard**
- **Code**
- **Native**

For more information, refer to [Creating Policies](/v1/docs/creating-policies).

---

### To create a Row Access Policy with the Policy Wizard:

1. **Fill in Policy Details.** For more information, refer to the Creating Policies article
2. Select **Use Policy For SaaS Applications** and select the Databricks application.
3. **Fill in Databricks POP Details** specific to the vendor Policy:
  - Under **Vendor Policy Kind** dropdown, select **Row Access Policy**. (Required)
  - Under **Vendor Policy Name**, enter a unique name (in small letters) for the Policy that will appear in the Databricks vendor. (Required)
    - **Note:** The same name can be used across multiple PlainID Policies to define multiple logic statements within a single Databricks Row Access policy (UDF).
  - Under **Vendor Policy ID**, note that the ID is automatically generated. It is the ID used in Policy management operations like deploy, update, and override.
  - Under **Vendor Policy Order**, define the execution order for the logical case statement within the same Vendor Policy ID. (Required)
    - Default value is 1. Use this field when enforcing multiple logic conditions for different Identity Groups within the same Policy.
  - Under **Comment**, add any additional information or clarifications about your Policy. (Optional)
  - Under **Catalog**, select the Databricks catalog where the Policy will be deployed.
  - Under **Schema**, select the schema within the catalog where the Policy resides.
  - Ensure that your Databricks app in Orchestration is switched to **Manage mode** to start building your Row-level Policy in the Policy catalog section. See Managing POPs for more information on how to change the POP Mode.
4. Click **Continue**.

---

## Who Section

In the **Who** section, you assign Row-level access by creating a new Dynamic Group or selecting an existing one. You can evaluate multiple Dynamic Groups (OR relationship between them) within a single Row Access Policy, enabling centralized and flexible access control logic.

**Define a new Dynamic Group** using the available vendor identity functions to grant access based on user identity parameters.

Supported Databricks identity functions include `is_account_group_member(group)`, `is_member(group)`, `session_user()`, and `current_user()`.

You can use multiple identity functions per Dynamic Group. To apply your Policy logic to all users, you can select the default **"All Users"** Dynamic Group.

---

## What Section

In the **What** section, you can define access through your Asset Types.

### Reusing Tables and Views

To apply different row filtering rules for different **roles**, **groups**, or **context conditions**, you can reuse the same **Vendor Policy Name** across multiple PlainID Row Access Policies.

This enables you to define multiple logical statements within a single Databricks Row Filter function (UDF), allowing flexible and centralized access control.

---

**To define access**:

1. Click **Add Asset Type**. Ensure that your Asset Type meets the [requirements](/v1/docs/databricks-row-level-access#asset-types-for-rowlevel-requirements) listed below
2. From the dropdown, select an **Asset Type**.
3. Select **existing Rulesets** for your Policy logic or create a new one. A Policy can include multiple Rulesets (OR relationship between them).
  - See [Defining a Ruleset for Row-level Filtering](/v1/docs/databricks-row-level-access#defining-a-ruleset-for-rowlevel-filtering) for more information.
4. Click **Save**.

---

### Asset Types for Row-Level Requirements

Ensure that your Asset Type/s meet the following requirements:

#### Table Mapping

**To set Table Mapping**:

1. In the Authorization Workspace, click on the **Assets & Conditions** tab.
2. Click on the relevant **Asset**.
3. Ensure that **"Is used for data filtering?"** is enabled.
4. Select **Set Table Mapping** to link your logical Asset Type with one or more physical Tables or Views in Databricks where the Row Access Policy should apply.
  - The mapping must include the fully qualified path (in lower-case) to the table or view, following the format:  

`catalog_name.schema_name.table_name`.

- These mappings are **reusable** and can support multiple policies.
- The mapping **must match** the Tables or Views that may be used in the policy.
- Only the Tables or Views **explicitly selected** in the Policy are **protected** by the Row Access Policy.

---

#### Attribute Mapping

**To set Attribute Mapping**:

1. Choose an **existing Attribute** or create a new one to use in your filtering logic.
2. Define the **data type** (for example, String, Numeric).
3. Enable **Available for Policies = Yes**. These attributes act as placeholders for filtering conditions.
4. Click **Set Data Column Mapping** to map the logical Attributes to one or more physical Databricks column/s (in lower-case).

Note: PlainID does not currently support ICEBERG Tables.

---

### Table/View Asset Type Prerequisites

The Table/View Asset Type represents the physical Databricks tables or views that are protected by the Row Access Policy.

To use Table/View Assets in a Row Access Policy, the selected Asset Type must already be configured with a valid **Table Mapping**. This mapping defines the relationship between the logical Asset Type used in the policy and the physical Databricks tables or views that may be protected.

Only discovered Table/View Assets that match the Asset Type table mapping can be associated with the policy.

---

### Table/View Assets

The Table/View Asset Type is automatically generated when the Databricks Policy Orchestration Point (POP) is created. It represents the discovered Databricks tables and views that can be protected by Row Access Policies.

These assets appear in the Assets section and are discovered from Databricks. Each asset represents a specific physical table or view.

When configuring a Row Access Policy, you select one or more of these discovered Table/View Assets to define which objects the policy protects.

Only the tables or views explicitly selected in the policy are secured by the Row Access Policy.

In order to use Table/View Assets within a Row Access Policy, the Asset Type’s Table Mapping must be predefined correctly. During translation, only mappings relevant to the selected protected Table/View Assets are used.

---

### Discovery Behavior

As part of discovery, PlainID creates the Asset Type and connects the relevant Ruleset. In addition, the system discovers and associates one or more Table/View Assets that represent the protected objects. These discovered assets are available for selection in the Table/View Asset Type and are associated with the policy based on the defined mappings.

**Notes:**

- A policy can be associated with one or multiple protected assets.
- Both tables and views are supported.
- The term **table** in this article may refer to either a table or a view, depending on the discovered object.

---

**To connect an Asset Type with the Databricks Application**:

1. Once the Asset Type is created, open the Databricks application.
2. Navigate to the **Asset Types** tab.
3. Click **Edit**.
4. Select the relevant **Asset Types** you want to associate with the Databricks application.

---

## Defining a Ruleset for Row-level Filtering

**To define a Ruleset**: In the Asset type within the Ruleset tab, define the Row-level filtering logic using the Asset Attributes you created (for example, `Status = 'Active'`).

You can use Databricks tables as an external Identity Source for contextual or dynamic rules (for example, `Project_id = Assigned_project`). See our article Managing Identity Source for more information.

Use PlainID's flexible logic to combine operators (`=`, `!=`, `>`, `IN`, etc.) with complex AND/OR relationships.

---

## When Section

In the When section, you define the Conditions that provide contextual identity data for your Policy, which determine when the Policy applies.

### To define a Condition:

1. Select an existing Condition or create a new one. A Policy can include multiple Conditions, combined with logical AND meaning all Conditions must be met for the Policy to grant access. Ensure that you select Conditions from Identity Attributes linked to the POP's Identity Source.
2. Click **Save**.

---

### Conditions for Row-Level Requirements

- Only Conditions based on **Identity Attributes** are supported for use in Row Access Policies.
- Ensure that an **Identity Source table** is defined within your Policy Orchestration Point (POP).
- Use an **Identity Attribute** that is mapped to one of the additional Identity Sources associated with the selected POP.
- Within a single Condition, you can only use Attributes from one Source.

---

## Deploying the Policy

Once complete, navigate to the Orchestration Workspace and deploy the Policy to Databricks.

Databricks enforces the access decision based on the Row-level filtering you've defined in the PlainID platform.

---

## Databricks Row Filters - SQL Function Structure

### Policy Syntax Table

| **Databricks terminology** | **Databricks Syntax** | **Description** | **PlainID terminology** |
| --- | --- | --- | --- |
| **Policy Declaration** | `CREATE OR REPLACE FUNCTION <Function_name>` | Defines the Function name. | Vendor Policy Name |
| **Policy Signature** | `AS (...) RETURNS BOOLEAN` | Declares arguments and return type. | Asset Type / Attributes |
| **Policy Logic** | `WHEN...`, `CASE...`, `EXISTS...` | Defines logic and identity checks. | Dynamic Groups + Rulesets |
| **Policy Evaluation** | TRUE / FALSE | Row inclusion or exclusion | Managed by PlainID |
| **Policy Application** | `ALTER TABLE ... SET ROW FILTER ...` | Applies function to table | Asset Type Data Settings |

---

## Row Filter Example

```
CREATE OR REPLACE FUNCTION Row_function_project(Status STRING, project_id int)
RETURNS BOOLEAN
RETURN
CASE
  WHEN is_member('project_manager')
    AND status = 'Approved'
    AND EXISTS (
      SELECT 1
      FROM project_assignments
      WHERE current_user() = employee_name
        AND project_id = assigned_project_id
    )
  THEN TRUE
  ELSE FALSE
END;

ALTER TABLE `product_demo`.`schema1`.`projects`
SET ROW FILTER `product_demo`.`schema1`.`Row_function_project`
ON (`status`, `project_id`);
```