Warehouse permissions and row-level security

Use this page to decide who can view, change, run and remove Warehouse objects, and to limit which rows and columns each role sees in a Warehouse table.

What each Warehouse permission allows

The four Warehouse object permissions sit in the Data Layer category, in the Granular tier. Give a role the permission that matches the work it does.

Give every role that works in the Warehouse View Warehouse Objects. The Warehouse item in the sidebar appears with View Warehouse Objects or Add/Modify Warehouse Objects, but the tree and saved views load only with View Warehouse Objects. A role with only Execute/Abort Warehouse Objects or Remove Warehouse Objects cannot open the page.

The permission is checked when the action runs, not when the page opens. A refused action starts with Access denied. Required permission(s): followed by the permission names, so the message tells you what to grant. Builder Minds make Warehouse changes with the permissions of the person messaging them, so the same gates apply: see Warehouse Builder and Lake Builder.

Running a Warehouse workflow needs separate workflow permissions. See Workflow permissions.

Use a preset for common roles

Two presets bundle the Warehouse permissions. They sit in the Data Layer category, in the Standard tier.

A Warehouse Administrator can view, run and modify Warehouse workflows, but cannot add or remove them.

In the High-Level tier, Data Layer Administrator includes Warehouse Administrator, and Data Layer Viewer includes Warehouse Viewer, together with the matching Lake, WriteBack and Lineage presets.

To assign a preset or single permission to a role, see Roles and permissions. The full list is in the Permission reference.

Give a role access to a table

Each table has its own Permission Groups. The admin group is always included and is hidden in the list.

1. Open the table from the Warehouse tree.
2. Go to General > Configuration > Permission Groups, and choose the role.
3. Click Apply. The button appears once you have made a change.

The groups you add here are the ones that row-level security and column permissions can use on the table. They also decide which tables a role can reach: a role only reaches tables whose groups include it, and the admin group reaches every table.

Restrict rows with row-level security

Row-level security (RLS) limits which rows each permission group sees. It is available on Dimension, Fact, Dictionary, Static and View tables. Open the table and go to RLS to set it up; the step's controls are covered in Row level security editor.

1. Go to RLS and set Protection to On. The change saves straight away, and the page confirms it with RLS enabled successfully.
2. Click New Query. Choose the permission groups for the rule block, then add the row conditions.
3. Set View to SQL to check the script. When it is generated for you, the confirmation reads RLS script generated successfully.
4. Click Apply. On a table you are still creating, the confirmation reads RLS settings saved successfully. On an existing table it reads RLS settings updated successfully.

Conditions combine with AND or OR, and NOT negates a group. Operators follow the column's type: text conditions can use in, contains and between, among others. The full list by type is in Row level security rules and operators.

A rule block can only target permission groups the table has. A block that names another role is refused with Roles not in table permission groups: ..., and a condition on a field that is not a column of the table is refused with Columns not found in table: .... On a deployed table, the script is run against the table before it is saved, so a filter the table cannot execute is refused with ClickHouse query failed. When a check on the rules fails, the popup reads Please check the RLS configuration.; when the save itself fails, it reads Failed to save RLS settings.

A group that no rule block targets is not restricted; the generated script records this with the note Roles without explicit rules see everything. What a group reads is also shaped by Security Labels: it sees the rows whose labels include it, or that carry no labels at all, and rows marked deleted stay hidden.

To write the filter yourself, set Editor to Manual. If the table already has rules, the page asks you to confirm Switch to Manual Editing first. A manual script is checked before it saves; these are refused: Forbidden keyword "..." found in script, Semicolons are not allowed, Line comments (--) are not allowed, INTO OUTFILE is not allowed and FORMAT clause is not allowed.

An Auto script is rebuilt whenever the table's permission groups change, so it always matches the current access. A Manual script never regenerates: the page keeps exactly the SQL you wrote.

Restrict columns

Column permissions limit a column to some of the table's permission groups.

1. Open the table and go to Columns.
2. In the Permission Group column, set the column to the groups that may see it.
3. Click Apply.

The admin group has full access to all columns by default. See Define table columns for the columns grid.

Limits and edge cases

• The RLS step needs at least one permission group you can see. Groups that are hidden from you are filtered out, and the admin group is always present but hidden, so a table with only the admin group shows Permission Groups Required with "You must add at least one permission group before you can configure Row Level Security. Add permission groups in the General tab to proceed." and a Go to General button.
• New Query is unavailable in Manual mode and while Protection is Off.
• Closing the expanded RLS view with unsaved changes asks Discard unsaved changes?
• You cannot remove a permission group from a table while a Mind linked to that table has the group as its owner role. The server refuses the change and names the Minds that block it.
• Reads and writes are layer-scoped. A role with View Lake Objects does not reach a Warehouse table, and a modifier from another layer cannot change one; reading a table and its dependants needs View Warehouse Objects.
• Refusals say what went wrong: a permission problem starts with Access denied. Required permission(s):, while a missing object, or an action that does not suit the object's kind, is refused with a message about the object.
• For more Warehouse messages and what to do about them, see Warehouse troubleshooting.

Questions, answered

Someone can see the Warehouse but gets "Access denied" on Deploy. What is missing?

They need Add/Modify Warehouse Objects. Deploying changes the table, so it needs that permission. View Warehouse Objects is not enough.

Which permission runs a transformation?

Execute/Abort Warehouse Objects tests, runs and aborts transformations.

Can a Warehouse Viewer test a transformation?

No. Testing needs Execute/Abort Warehouse Objects, and the Warehouse Viewer preset does not include it.

Do I need View Warehouse Objects to open the Warehouse?

Yes, in practice. Add/Modify Warehouse Objects alone shows the Warehouse item in the sidebar, but the tree and saved views load only with View Warehouse Objects. Give both to a role that changes Warehouse objects.

Is the admin group always allowed?

Yes. The admin group is added to every table and has full access to all columns. It is hidden in the Permission Groups list.

What happens when Protection is Off?

Every permission group can access all rows of the table.

Can I write the RLS filter in SQL?

Yes. Set Editor to Manual and write the SQL yourself. The script is checked when you save: forbidden keywords, semicolons and line comments are refused. Switching back to Auto discards your edits.

Why is my RLS save refused?

The save checks three things: every rule block must target permission groups the table has, every field must be a column of the table, and on a deployed table the script must run. A refused save shows Please check the RLS configuration. or Failed to save RLS settings.; fix the roles or fields it names and save again.

Who sees the rows that no rule covers?

A permission group that no rule block targets is not restricted: it sees every row of the table. The generated script notes this with Roles without explicit rules see everything. Add a block for the group to limit it.

Can I hide one column from a role?

Yes. In Columns, set the column's Permission Group to the groups that may see it, then click Apply.

Does Warehouse Administrator let me manage workflows?

Partly. It lets you view, run and modify Warehouse workflows. It does not let you add or remove them. See Workflow permissions.

Can I remove a permission group that a Mind uses?

Not while a Mind linked to the table has that group as its owner role. The server refuses the change and names the Minds that block it.