Record Level Security

Record-Level Security (RLS) uses filter-based policies to control which records each role, team or user can see in a table. Table permissions and field permissions apply to full tables or columns. RLS applies at the record level, so that users see only the data that is relevant to them.

When to use RLS:

• Sales reps must see only their own deals.
• Regional managers must see the records for the territory of their team.
• Support agents must access only the tickets assigned to them.
• Department heads must see the records across their team hierarchy.

Enabling Record-Level Security

1. Open the table where you want to configure RLS.
2. In the sidebar, click the ⋯ icon next to the table name.
3. Select Record-Level Security.

The RLS management panel opens. Create and manage the policies for this table in this panel.

Key Concepts

Policy Types

RLS uses two types of policies:

Default Policy Behaviors

The default policy sets what happens when a user does not match a scoped policy:

When a table has no RLS policies, all users can see all records (the same as "Show all").

Subjects

Each scoped policy applies to one or more subjects. Subjects are the roles, users or teams that the policy is for:

For team subjects, you can select the hierarchy scope:

Filter Conditions

Policies use the standard NocoDB filter builder to set conditions. Users who match the subjects of a policy see only the records that match its filter conditions.

Filters support all standard operators (equals, contains, greater than and others). They can refer to any field in the table. You can also make nested filter groups with AND/OR logic.

RLS filters can also refer to the system fields Created by, Last modified by, Created time and Last modified time. Usual view filters do not show these fields.

Dynamic Values

In a condition, you can refer to the user who sees the data, not a fixed value. NocoDB gets a dynamic value from the signed-in user each time the policy runs. Thus, one policy covers all people in the workspace. You do not need a copy for each person.

To use a dynamic value:

1. At the end of a filter condition, click the settings icon.
2. Select Dynamic value.
3. Select a value from the list.

The list shows only the values that fit the condition. Thus, you do not always see all entries.

The field type sets which values show:

The operator limits the list more. Each team value gives a list, so team values show only with the multi-value operators: contains any of, does not contain any of, contains all of and does not contain all of. Single-value operators, such as is equal, show only the current-user values.

Policy Resolution Order

When a user asks for data from a table with RLS, NocoDB examines the policies in this order:

1. Check scoped policies: The user can match one or more scoped policies (by role, user ID or team membership). If so, NocoDB combines the filters of those policies with OR logic and applies them.
2. Fall back to default policy: If no scoped policy matches, NocoDB applies the default policy behavior (show all, deny all or condition-based filter).
3. No policies configured: If the table has no RLS policies, all records are visible.

NocoDB combines RLS filters with the view filters by AND logic. Thus, a record is visible only if it matches both the view filter and the RLS policy filter.

Managing Policies

Creating a Default Policy

1. Open the RLS panel for the table.
2. Click Add Default Policy.
3. Select the default behavior:
   • Show all: Unmatched users see all records.
   • Deny all: Unmatched users see no records.
   • Condition: Set filter conditions for unmatched users.
4. If you selected Condition, use the filter builder to set the filter conditions.

Creating a Scoped Policy

1. Open the RLS panel for the table.
2. Click Add Policy.
3. Type a policy name (for example, "Sales reps see own deals").
4. In the Apply To section, select the subjects of this policy:
   • Select from Roles, Members (users) or Teams.
   • You can select many subjects of different types.
   • For teams, select the hierarchy scope (self only or self and descendants).
5. Set the filter conditions that control which records are visible.
6. Save the policy.

Enabling and Disabling Policies

Each policy has an enable/disable toggle. NocoDB ignores disabled policies. A disabled policy keeps its configuration, but it does not change which records are visible.

Editing and Deleting Policies

• To edit a policy, click the edit icon next to it in the policy list. Change the name, subjects or filter conditions.
• To delete a policy, click the delete icon. Then confirm the deletion.

Example: Sales Pipeline

A "Sales Pipeline" table keeps track of the deals of a sales organization:

Goal: Sales reps see only their own deals. Regional sales managers see the deals in their region. By default, all other users are blocked.

Policy 1: Default Policy — Deny All

Create a default policy with the behavior Deny all. A user who does not match a scoped policy then cannot see records.

Policy 2: Sales Reps See Own Deals

Sales reps (with the Editor role) see only the deals assigned to them. The filter uses a dynamic value, so this one policy covers all reps. For each rep, NocoDB compares Assigned To with the email address of that rep.

Policy 3: Regional Managers See Team Deals

Members of the North Sales Team (and its sub-teams) see all deals in the North region. Create similar policies for the other regions.

How It Works

Notes and Limitations

• Permissions required: Only base Owners and Creators can create, edit or delete RLS policies.
• Per-table limit: The number of scoped policies for each table has a configurable limit. The default policy does not count toward this limit.
• Fail-closed: If an error occurs while NocoDB examines the policies, NocoDB denies access. Thus, a system error never shows records.
• API and views: RLS policies apply to all views of the table and to API calls. No interface gives access to records that RLS filters out.
• Table visibility first: NocoDB applies RLS only after table visibility. If a table is hidden from a user, RLS does not apply. The user cannot access the table at all.
• View filter interaction: RLS filters combine with view filters by AND logic. A record is visible only if it matches both the view filter and the RLS policy filter.
• Real-time updates: Policy changes apply immediately for all connected users.

Related topics

• Roles & Permissions
• Table Permissions
• Field Permissions

Availability

• Record-level security is available on NocoDB Cloud (Scale plan and above) and licensed self-hosted deployments (Scale plan and above).