Set Row Access

Description

Set Row Access recomputes a governed column’s Row Access grants from a source table and applies them. Point the column at a table where each row pairs a security group with a value that group may see, and this step reads those rows and writes the resulting grants — so Row Access stays current as the source data changes, with no one hand-editing the grid.

The column must already restrict rows — set it up in the Row Access grid first. The step’s first run binds the column to the source table: the column’s hand-set grants are cleared and replaced by the table’s rows. From then on the column shows locked in the Row Access grid with a source badge, and hand-editing it there is refused until someone clicks Remove Binding. See Binding Grants to a Source Table in the Row Access guide.

Use this to keep grants in sync with changing data

A typical use is scheduling this step after the workflow that loads or refreshes the source table, so a new group, a removed value, or a reassigned territory reaches Row Access automatically on the next run — instead of someone remembering to update the grid by hand.

Parameters

• Project — the project whose governed column this step updates.
• Column — the governed column, picked from the project’s actual columns.
• Source Table — the table supplying (group, value) rows. Naming a different table from the one the column is bound to rebinds it to the new table.
• Group Column — the source table’s column naming the security group.
• Value Column — the source table’s column naming the value that group may see.

Behavior

Each run reads every (group, value) row currently in the source table and replaces the column’s grants with exactly that set — a group no longer present in the source table loses every grant this step previously gave it. Rows naming a security group that doesn’t exist are skipped rather than failing the step. The update reaches both PlaidCloud’s own queries and Superset dashboards the same way a manual save does, typically within about a minute.

Because the source table decides who sees what, only a project Architect, a tenant admin or the project’s own workflows can change its rows or delete it once it is bound.

Caution

This step replaces the entire set of grants it manages. If you maintain some of a column’s grants by hand and others from a source table, keep the two on separate columns — hand-edited grants on a source-bound column are not preserved between runs.

Examples

No examples yet.