Managing Security Groups and Assignments

PlaidCloud’s security and access management is straightforward. A member is granted or denied access based on the groups in which a member is associated. Adding or changing a member’s security association is easily customizable.

Managing Security Groups

Security groups can be added, updated, or deleted.

To manage security groups:

Open Identity
Select the “Security” tab
Click “Security Groups” in the dropdown menu (this will display a form with existing groups)
To add a group, click the “Create Security Group”
To edit permissions of a group, click on the left-most icon

To manage group members:

Open Identity
Select the “Security” tab
Click “Security Groups” in the dropdown menu
Click the Member icon
Drag desired members from the “Unassigned Members” column to the “Assigned Members” column or vice versa to remove members

Managing Row Access

Row Access restricts which rows of a table a security group can see, based on the value of one column. For example, a region column can restrict access, with a group granted East and Central limited to rows carrying those values. Everything for a project and column — picking the column, choosing where its values come from, and deciding which group sees what — happens in a single screen, and saving it takes effect immediately.

Setting up and changing Row Access takes a project Architect or a tenant admin. Anyone else who opens a project’s Security tab is told that row access is Architect-only, and the entry points below don’t appear for them.

Opening Row Access

Every entry point opens the same Row Access screen:

Table Explorer’s toolbar has a Row Access button, with a badge when the table already restricts rows. It opens on the table’s first restricted column, if it has one, and you can switch to any other column of the table.
A column’s facet menu has Restrict rows by this column…, which opens Row Access on that column. On a column that already restricts rows, the item reads Rows restricted by this column — edit….
A project’s Security tab lists every restricted column on the project, with the tables it applies to, the groups that hold grants, and its Sync state. Select a column to edit it, or click Restrict a column… to start a new one: pick a table, then a column. Columns that already restrict rows are marked with a lock.
Identity → Member, on a member’s Row Access tab, and Identity → Security → Security Groups, on a group’s Row Access summary. Open Row Access (or Edit) opens the selected column; Add restricts another column in that row’s project.

Opened on a column, the screen stays on that column. Opened with Restrict a column… or Add, it lets you choose one.

The Row Access Grid

To restrict a table by a column:

Open Row Access from any of the entry points above, and choose the column if you didn’t arrive with one — the picker offers the table’s real columns, not free text.
Choose a Value Source — Column (the distinct values of a table’s column), Dimension (nodes of a dimension), or List (values you type in). The value type follows the column’s data type.
For each security group, check the values that group may see. The grid lists the groups with access to the project, plus any group that already holds a grant on the column.
Set Everyone else to sees all rows or sees no rows — this covers any group with no checks in the grid.
Click Save.

Saving is live. PlaidCloud’s own queries follow the change at once and your Superset dashboards within about a minute — there’s no separate step to apply it and no approval dialog. The screen’s sync status shows how far the change has got; see Keeping Dashboards in Sync.

The grid also handles the details for you:

Many values. Values are sorted. When a column has more values than fit, the grid says “More values than fit here — type to search.” and the filter box searches the whole column, keeping every value a group already holds.
Blank values. One Blank values — visible to every group with a grant checkbox decides the rows with no value in the column. Tick it and every group with any grant on the column sees those rows.
A table that isn’t built yet shows Build this table first (run the workflow that creates it) instead of an empty list.
Save waits for the values on screen. While values load — after you switch the value source, dimension or table, or apply a template — Save is disabled with the tooltip “Save is available once this source’s values load.” If a load fails, the grid says so and asks you to pick the source again; nothing is saved until a load succeeds.

One Column Name, Every Table

A restriction belongs to a column name on the project, not to a single table. Once region restricts rows, every table in the project with a column named region is filtered by it, in PlaidCloud’s own queries and in dashboards alike. The grid’s Applies to list shows those tables. It is read-only, because the column name decides it, and a table you add later with the same column is covered as soon as it’s published.

Stopping a Restriction

Stop restricting, on the grid, removes the restriction after an inline confirmation — “Stop restricting rows by ‘region’? Every group’s grant on it is removed and everyone sees its rows.” Row Access then confirms “Rows in ‘region’ are no longer restricted.” The column’s Superset dataset goes with it, unless charts still use it; in that case Row Access says the dataset stays and how many charts use it.

A column can’t be renamed or dropped while it restricts rows. An Architect is told to stop restricting it in Row Access first; anyone else is told to ask a project Architect.

Who Can Change a Project That Restricts Rows

A project’s workflows, steps and user-defined functions run as the project’s own service identity, which reads every row. Whoever can change them could make a step copy rows they aren’t granted into a table they can read, so restricting rows on a project also restricts who may change what the project does. Once a project restricts at least one column:

Automation is Architect-only. Only project Architects and tenant admins can change workflows, steps, user-defined functions, schedules, workflow and project variables, and notify email templates — and, for the same reason, import a workflow bundle, convert an Alteryx workflow, or import, copy or restore into the project, or change its connection environment, default document account or ERP posting mode. Everyone else can still run the project’s workflows: Start, Stop, Resume and Run Selected Step(s) stay available. The step editor, the workflow’s authoring controls, the UDF editor and the schedule form open read-only for them, with a banner that names the Architects to ask: “This project restricts rows, so only its Architects can change workflows, steps, UDFs, schedules, variables and notify templates. You can still run them.”
Dimensions a restricted column reads are Architect-only. A dimension that decides who sees which rows — the value source of a restricted column — can be changed only by a project Architect or a tenant admin, and by the project’s own workflows. That covers adding, moving, renaming, copying, clearing, loading and restoring its nodes, and the dimension itself. Anyone else is told “This dimension decides who sees which rows of ‘region’, so only a project Architect can change it.” Dimensions no restriction reads are unaffected.
A grants source table is Architect-only. A table bound as a column’s source of grants can have its rows changed, or be deleted, only by a project Architect, a tenant admin or the project’s workflows — through the Data Editor, an import, a connector load or the API alike.
Copying the project is Architect-only, and the copy says “This copy is not row-restricted.” — the new project carries no restriction until you set one up.
Restoring an earlier version is a change like any other. Restoring the project’s own settings, or a dimension listed above, takes a project Architect. A restore always applies to the item the version belongs to, so it can’t be pointed at another project to get around this — see Version History.
Editing data in a restricted table needs an Architect, as described under Row Access and the Data Editor.

Before the first column on a project is restricted, Row Access tells you who this affects: “Restricting rows here means only Architects can change this project’s workflows, steps, UDFs, schedules and notify templates. N members can change them today; they will still be able to run them.”

Runs keep working exactly as before, scheduled ones included, because they run as the project’s service identity. What a run produces follows the design its Architects gave it: an output table without the restricted column, an export file, a notification email or a log line is not filtered for whoever reads it.

Values given at the start of a run. Anyone who can run a workflow can start it with values of their own for its variables — the App Runner does this with its form’s answers, and the API and AI tools can too. Those values hold for that run only: they are never saved on the workflow, and no other run, export or reader sees them. Because the run executes as the service identity, the values can change what that run reads and writes, so grant permission to run workflows to people you trust with that.

Projects that restrict no rows. These rules take effect only once a project restricts a column. On a project that restricts none, anyone who can change the project’s automation can write a step or user-defined function that — running as the project’s service identity — changes the project’s access, making themselves one of its Architects. That is by design: such a project promises no row isolation. Keep authoring rights there to people you’d trust as Architects, or restrict a column.

Keeping Dashboards in Sync

Row Access shows where a change stands on the way to your dashboards, on the grid and in the Sync column of the project’s Security tab:

Status	What it means
Waiting	A change is saved and on its way to dashboards. It normally clears within about a minute.
Retrying	A send failed and is being tried again. The reason for the failure is shown next to the status, with Retry to send again right away.
Not applied yet	The project’s restrictions have not been sent to dashboards yet.
Applied	The last attempt to send the restrictions to dashboards succeeded.
In sync with dashboards	Row Access compared what dashboards enforce with what it would write, and they match.
Dashboards differ	Dashboards don’t enforce what Row Access would write — a rule was changed or deleted in Superset, or a table’s published view can’t be checked.
Error	Sending the restrictions failed. The reason is shown next to the status.

Once a change reaches Applied, the grid checks it against dashboards and moves on to In sync with dashboards or Dashboards differ. Dashboards differ and Error both offer Retry, which sends the project’s restrictions again. If the status can’t be read at all, the grid says “Couldn’t check sync status.”

An Error caused by one table names the table and says what to do — for example, a table published without its restricted column (“Republish or unpublish it.”), or a table with a restricted column that isn’t published, which dashboards can’t filter until it is. The status stays on Error and names the unpublished table until you publish it, or restrict the column on a published table instead. A table like that doesn’t hold up the rest of the project: every other table is kept in step.

Dashboards follow the same grants as PlaidCloud’s own queries:

Every published table with the column is filtered, not only the table you were looking at when you set the restriction up.
A group granted only some values is filtered even when everyone else sees all rows, on every table whose dashboard dataset exists.
Security group membership changes reach dashboards on their own. Adding someone to a group or removing them in PlaidCloud, disabling or deleting a member, deleting a group, or adding a new member who joins your default security groups updates what they see in dashboards within about a minute, on every project that grants that group values, without anyone reopening Row Access. A membership change made outside PlaidCloud — directly in Keycloak, or by single sign-on placing someone in a group at sign-in — reaches dashboards within about 15 minutes, with nothing to save or retry.

Dimension Grants

With Dimension as the value source, check a node to grant everything under it. The grant follows the dimension: a member added under a checked node is granted to that group on the next sync after the dimension is saved, and a member moved out from under it, or removed, stops being granted — nobody needs to reopen the grid. When you do reopen it, the nodes you checked show checked again.

Unchecking anything beneath a checked node unchecks the node, and the group keeps only the members still checked. Checking that member again doesn’t check the node again — click the node’s own box for that. Paste, Select All and Invert check members, never nodes.

A dimension member whose name can’t be used as a row-access value is refused when you save, naming it. If such a member appears later, its rows are not granted to anyone, and the sync status names it: “Dimension ‘…’ member ‘…’ cannot be used as a row access value, so its rows are not granted. Rename it in the dimension.”

Binding Grants to a Source Table

Instead of checking values by hand, you can point a restricted column at a source table that already holds the answer — one row per group and the value it may see. Restrict the column in the grid first, then add a Set Row Access workflow step naming the column, the source table, and the source table’s group and value columns. The step’s first run binds the column to that table: the column’s hand-set grants are cleared, and its grants are set from the table’s rows.

Once bound, the column is source-owned: the Row Access grid shows it locked, with a badge naming the source table, and hand-editing its grants is refused until you click Remove Binding.

Each later run of the step re-reads the source table and re-applies the grants — schedule it after the workflow that loads or refreshes that table, and a group added, removed, or reassigned in the source data reaches Row Access on the next run, with nobody editing the grid by hand.

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. Anyone else is told “This table supplies the row access grants for ‘region’, so only a project Architect can change its rows or delete it.”

Restriction Templates

If you’ve built a restriction shape you want to reuse — the same value source, value type, and blank-value setting — save it once and apply it wherever it’s needed, rather than rebuilding it column by column.

Save as Template…, from an open Row Access screen, saves the current column’s shape as a named, tenant-level template. It saves the shape only — no grants travel with it.
Apply Template, on another project’s column, starts that column from the template’s shape, with every group’s grants empty for you to fill in.

Any project Architect can save and apply templates. Renaming (Rename…) and deleting (Delete) a template takes a tenant admin, since a template is shared across the tenant. Deleting one leaves the columns it was applied to restricted as they are.

Grants from SSO Group Attributes

A column can also take its grants from your identity provider instead of from PlaidCloud. A project Architect opts a column in from Row Access by enabling Accept row-access grants from SSO group attributes.

Once enabled, a security group’s Keycloak attribute row_access.<column> sets the values that group can see through that column — set the attribute on the group in Keycloak, and PlaidCloud picks it up automatically for any group that already has access to the project. There’s nothing further to configure in Row Access itself, and the grants stay in sync in both PlaidCloud’s own queries and Superset dashboards.

Previewing Before You Save

Row Access shows you what a change means before you commit to it:

A Preview as footer shows how many of the table’s rows a group would see out of the total, with a sample of the rows themselves — pick any group in the grid to preview it. The preview refreshes after you save.
Before you save, Row Access warns you about anything worth a second look: a group with nothing checked, and whether that means it sees all rows or none under your Everyone else setting; members with project access who aren’t covered by any group’s grant; or rows whose value in that column is blank (NULL) that no group is granted.

What a Restricted Member Sees

Wherever a restricted member reads a table by name, they get only their rows — Table Explorer’s grid, column facets and downloads, the table download dialog, apps and tools that read as the viewer, and dashboards. Table Explorer shows Rows limited by your access in its toolbar when the grid you’re looking at was filtered by your grants, and starting a download that will be filtered says “Rows limited by your access.” An Architect, who reads every row, sees neither notice.

Row Access and Queries You Write Yourself

Row Access limits which rows a group may see by filtering the table it is defined against. A query someone writes themselves has no single table to attach that filter to — a query can join, combine or nest as many tables as it likes — so on a project that restricts rows, PlaidCloud declines to run a query supplied by the caller rather than return rows nothing has vetted.

This applies to reading through your own SQL, exporting the results of your own SQL to a file or to another database, and typing a row condition into a fan-out step’s “Test row 1” preview. It does not apply to reading a table by name, which is the ordinary way apps and tools read data — those apply the grants and return the rows the viewer is entitled to. A column facet written as a plain query of a single table is read by name too, so it returns the member’s own values rather than being declined.

Anyone declined is told which project it was, and pointed at the by-name readers. A project Architect can run the query as written, and export its results in any format, because an Architect can already grant themselves every value of every restricted column.

Importing a spreadsheet is not, by itself, a query you wrote yourself — an ordinary file import reads no restricted data at all, it only creates the project’s own new table from the file you uploaded, so it is unaffected by Row Access. The exception is an import whose data projection is caller-supplied: a per-column expression, or a dynamic Excel mapping. On the interactive import screen those are declined the same way as the free-form-SQL surfaces above, and need a project Architect, because a caller-supplied projection could read another table. An import run from a workflow is unaffected either way, since it runs under the project’s own service identity.

Row Access and the Data Editor

The Data Editor reads and writes a table directly, so Row Access applies to it on both sides.

Opening a restricted table in the Data Editor shows only the rows your security group is granted — the same filter that follows you into a dashboard, and it applies even when the restricted column is not one of the columns shown in the grid.

Saving your edits requires Architect on the project. A save replaces the table’s rows wholesale rather than reading them, and it is not filtered row by row, so editing data on a restricted table is treated as an authoring action rather than a read: anyone without Architect is told they need it. A table that carries no restricted column is edited as before, and so is any project that restricts no rows.

Row Counts and Table Sizes

A table’s row count and storage size describe the whole table, not the rows you may see, so they would tell a restricted reader how many rows exist beyond their grant. On a project that restricts rows, anyone whose reads are filtered sees no row count or size for any of the project’s tables — in table lists, search, table details and snapshots, and through the AI assistant and AI tools connected over MCP. This covers every table in the project, including tables with no restricted column. The project’s own totals are hidden from them too — the total row count and size on Home, in project lists and search, and in project details.

The same applies to workflow run history. The rows read and written that each run and step recorded describe the whole table too, so for the same readers those figures are left blank — in a workflow’s and a step’s run history, and through the AI assistant and AI tools connected over MCP. For them, Weave does not check steps for rows or empty values unlike previous runs, since a finding would itself tell them the whole table’s count had moved.

Project Architects see the figures as before, and so does everyone on a project that restricts no rows.

Seeing What a Member Can See

To check what a specific person can see, rather than what a group is granted: open Identity → Member, select the member, and open their Row Access tab. Its Effective Access column lists, for every restricted project and column, the values that member sees through all of their groups combined — including grants from SSO group attributes and blank (NULL) rows where a group’s grant includes them. A project Architect shows as Sees every row (Architect), since an Architect reads every row. It is the same answer PlaidCloud’s own queries apply, so it’s useful for support and for confirming a change did what you meant before someone reports a problem.

Clearer Errors

Where Row Access blocks an action — a query you wrote yourself on a restricted project, an edit without Architect, a change to automation, a dimension or a grants source table, and the other cases described above — the message names what is restricted and what to do next, such as the Architects to ask, instead of a generic failure.

Row Access Is Audited

Restricting or un-restricting a column, and editing a group’s grants, all write an entry to that project’s Project Log — who made the change and when. Open Analyze → Projects → Log on the project to see it. Nothing about Row Access has to be turned on to get this trail; it’s recorded the same way every other tracked change to a project is.

Setting Default Security Groups

To reduce the time needed for adding new members, identify a set of default security groups. This provides a baseline set of security groups for new members without needing to manually assign each person. The setting is available when adding a new security group if you check the box at the bottom of the Security Group window that reads “Assign to New Users by Default”.

Performing a Security Audit

The security audit capability provides the ability to see group membership across all members and groups.

To perform a security audit:

Open Identity
Select the “Security” tab
Click “Security Group Audit” in the dropdown menu

As all tables in PlaidCloud are exportable as a CSV file format, the group member associations are reviewable outside of PlaidCloud for either historical purposes or just some fun off-line viewing.

To export from the “Security Group Audit” form:

Open Identity
Select the “Security” Tab
Click “Security Group Audit” in the dropdown menu
Click the small icon to the far right of “Username” in the table
Click “Export CSV” or “Export XLXS” depending on your preference

Viewing Available Permission Settings

Each application being used in the workspace has specific available permissions. The security group permissions are based on these application permissions.

The complete list of available permission for each application is viewable from the Security Bin.

To access the Security Bin:

Open Identity
Select the “Security”
Click “Security Bins” in the dropdown menu

To view the detailed security settings for each application, select the tags icon on the far left.

This available security settings information is informational only. For details on managing permissions, refer to the Managing Security Groups section above.