Control Who Sees What

~20 minutes · a security group, assigned members, scoped access

You’ve just been made an administrator of a PlaidCloud workspace, and people are waiting to get in — but not everyone should see everything. This tutorial walks the whole path once: get the right people into the workspace, bundle a set of permissions into a security group, assign members to it, and then narrow what that group can reach down to the project and, where it’s set up, the individual row.

The pieces you’ll touch — organization, workspace, member, security group — fit together in a fixed way. If the model is new to you, read Identity and Access Management (IAM) first; it has the diagram. The short version: an organization contains workspaces, a workspace contains members, and a security group is a bundle of permissions inside one workspace that you assign members to. Nothing here leaks between workspaces — each one manages its own access.

Most of what follows happens in the Identity tab on the left side of the workspace. You’ll need enough administrative access to manage security there.

You can only hand out what you hold. When you save a group’s permissions, PlaidCloud silently leaves alone — and doesn’t even show you — any permission you don’t have yourself. If a capability you need to grant isn’t in the matrix, ask someone who holds it. The matrix only ever edits what you control.

Step 1: Get the Right People Into the Workspace

A security group can only be assigned to a member who is already in the workspace, so start there. A member has to be part of the organization and appear on the member management form before you can add them to a workspace.

To add a new member to the workspace:

Open Identity and select the Member tab.
Click All in the dropdown menu to list current members.
Click Add Workspace Member, complete the required fields, and click Create.

The new member receives a welcome email with sign-in credentials automatically. To add someone who is already in your organization to this workspace, use Organization Settings (upper-right menu) → Workspaces → the members icon, then drag them into the workspace and click Submit. If the person isn’t in the organization at all yet, use the invite icon on the same screen to email them an invitation.

Membership is the outer gate, not the fine-grained one. Being in the workspace lets a member reach it at all. What they can do once inside is decided by the security groups they’re assigned to — which is the next three steps.

For the full add / invite / remove flows, see Managing Workspace Members and Member Management.

Step 2: Create a Security Group

A security group is a named bundle of permissions. Rather than grant capabilities to one person at a time, you define the bundle once and assign people to it.

Open Identity and select the Security tab.
Click Security Groups in the dropdown menu. Existing groups appear in a form.
Click Create Security Group and give it a clear, role-based name — Analysts, Report Viewers, Workspace Admins.
To set the group’s permissions, click the left-most icon beside it to open its permission matrix, choose the capabilities this group should have, and save.

The permissions available in the matrix come from the applications in your workspace — each application publishes its own set. To browse the full list of what any application offers before you build a group, click Security Bins in the Security dropdown and open an application with the tags icon on the left. That view is informational; you actually grant permissions in the group matrix above.

Fewer groups, not more. A workspace allows unlimited security groups, but every extra group is another thing to reason about at audit time. Model groups on real roles people share, and keep the count as low as the work allows.

Step 3: Assign Members to the Group

With the group defined, put people in it.

From Identity → Security → Security Groups, click the Member icon beside the group.
Drag the people who should have this group’s permissions from the Unassigned Members column into the Assigned Members column. To take the group away from someone, drag them back the other way.
Save.

That’s the whole grant: a member in the Assigned Members column holds every permission the group bundles; a member who isn’t, doesn’t.

An empty assignment does nothing — on purpose. Saving the group with the Assigned Members column empty makes no change and tells you so. To take a group’s power away from everyone, remove its permissions or delete the group — don’t try to revoke it by emptying the membership list.

Optional: Make a Group a Default for New Members

If every new member should start with a baseline — say, read access to shared reports — mark a group as a default. New members are then assigned to it automatically, so you don’t have to remember to do it by hand. When creating or editing a group, check Assign to New Users by Default at the bottom of the Security Group window.

Step 4: Scope What the Group Can Reach

You now have members carrying a defined set of permissions. PlaidCloud scopes access in progressive layers — organization → workspace → project — so you can tighten from the outside in:

Layer	What it gates	Where you set it
Workspace	Whether a member reaches the workspace at all	Workspace membership (Step 1)
Security group	Which capabilities they hold once inside	Group permissions (Step 2)
Project	Architect and other project-level rights	Security group permissions, per project
Row (optional)	Which rows of a governed table a group sees	Row Access (below)

For most teams the first three layers are enough: put people in the workspace, give each group only the permissions its role needs, and scope project-level rights — such as Architect on a project — through the group’s permissions. A group with no rights on a project simply can’t act on it.

When You Need Per-Row Control

When two people should see the same table but different rows of it — each regional manager only their own region — reach for Row Access. It lets you designate a column on a project (for example region) as governing which rows a security group may see, then grant specific values (East, Central) to specific groups. It’s the finest-grained layer, and it’s optional: leave it off and a group sees every row its other permissions allow.

Row Access is opened from the Row Access icon beside a group in Security Groups, and its grants have to be applied before they reach dashboards. The mechanics — declaring a governed column, granting values, and applying to dashboards — are covered in full under Managing Row Access; this tutorial deliberately stops at pointing you to it.

Row Access follows the person, everywhere they read. Once applied, a group’s row grants filter what its members see in dashboards and in apps that read as the viewer — the same per-viewer model a Panel app uses when it authenticates as the signed-in user. See Reading Data and the Signed-In User for that path.

Step 5: Check Your Work

Before you call it done, confirm the assignments are what you think they are.

Open Identity → Security and click Security Group Audit in the dropdown menu.
Review group membership across every member and group in one place.
To keep a record, click the icon to the far right of Username in the table and choose Export CSV or Export XLSX.

Re-run this audit whenever roles change — it’s the one screen that shows the whole picture of who is in which group.

You’re set. You now have a security group, members assigned to it, and access scoped from the workspace down to the project — and, where you need it, the individual row.

Where to Go Next

Managing Security Groups and Assignments — the full reference for groups, Row Access, default groups, and the security audit
Identity and Access Management (IAM) — the access model, the diagram, and where every access guide lives
Organizations and Workspaces Explained — the boundaries between the layers you scoped in Step 4
Managing Workspace Members — inviting, adding, and removing members
Reading Data and the Signed-In User — how the same per-viewer access model carries into apps that read data as the person looking