The Conditions and RLS steps of a Lake table's popup decide which rows the table loads and which rows each permission group sees in it. Use Conditions to leave rows out of every load, and RLS to give different permission groups different rows of the same table.
Both steps sit on the Table tab, after General and Columns. Configure a table shows how to open the popup and how steps save.
A business condition is a SQL WHERE clause that filters which rows a load reads: only the rows that match it are loaded into the table.
The same condition editor appears as the Criteria column in the Batch edit grid, where you can change the condition for several tables at once. See The Batch edit grid.
Row-level security (RLS) lets each permission group read only the rows that match its own rules. It applies when someone reads the table; it does not change what a load reads.
The step needs at least one permission group on the table. Without one, RLS shows Permission Groups Required with the message "You must add at least one permission group before you can configure Row Level Security. Add permission groups in the General tab to proceed." Click Go to General, add a group under Permission Groups, then return to RLS.
The step opens the shared row-level security editor: a Protection switch, rule blocks you add with New Query, and an editing mode of Auto or Manual. Row level security editor walks through the editor; Warehouse permissions and row-level security explains what row-level security does on Warehouse tables. Permission groups that are hidden are left out of the editor.
Apply saves the step once it has unsaved changes. A successful save reports RLS saved successfully. If it fails, the message reads Failed to save RLS settings and carries the server's reason. The settings attach to the table, so they save against a saved table; without one, the save is refused with Table ID is required for saving RLS settings.
Saving either step needs Add/Modify Lake Objects; View Lake Objects lets you read a table's settings. See Who can do what in the Lake.
It filters which rows a load reads: only the rows that match the clause are loaded into the table, and the rest are left out of the load.
When you save it with Apply. The condition is part of the table's load settings, so loads after that read only the rows that match it.
No. It only decides which rows a load reads; nothing is written back to the source.
Yes. The same editor opens from the Criteria column there, so you can change the condition for several tables at once. See The Batch edit grid.
The step needs at least one permission group, and shows Permission Groups Required until the table has one. Click Go to General, add a group under Permission Groups, then return to RLS.
The settings attach to a saved table, and this table is not saved yet. Save the table first, then save the step again.
No. They act at different points: the condition decides which rows a load reads, and row-level security decides which of the loaded rows each permission group sees. A table can use both.
Saving either step needs Add/Modify Lake Objects. Reading the settings needs View Lake Objects. See Who can do what in the Lake.