Stacker

Search Documentation

Search for pages and topics in the documentation

4 min read

Permission Overview

Portal users only see certain rows in each table—never the whole table by default. You choose those rules per table: for each one, you define how a row is tied to the logged-in user (for example a relation or matching field that points at their portal user record), and that setting filters which records they get.

How table permissions work

Your portal has a users table (the table whose records represent people who log in). Other tables—projects, orders, tickets, and so on—should only expose rows that are linked to the current user's record in that users table, or that match a field path derived from that user (for example, the same client or account).

If a table has no rule that connects its rows to the current portal user, portal users won't get access to that data. Shared reference data (statuses, categories, catalogs) can be opened up so every portal user sees all rows in that table when you intend it to be shared.

Set it up with the AI agent

You don't have to configure everything by hand. Describe your app and who should see which data to the AI agent in the builder—it can set the users table and wire up per-table access so rows are scoped to the right portal user, including indirect paths through related records.

Example prompts for the AI agent

Scoped to the customer

"Only show each customer their own orders and invoices, linked through their contact record."

Staff in a users table

"Portal users are employees in the Staff table; they should see projects where they are on the team."

Shared reference data

"All portal users should see every row in the Products and Status tables."

After the agent applies changes, review the result in portal settings and adjust if needed.

Set it up in portal settings

Open Portal settings and go to the Permissions tab. There you can:

Choose the users table

Select which table stores portal logins and map the email (and name) fields so each signed-in user matches a row in that table.

Connect each data table to users

For every table portal users should see, set how rows relate to the current user—for example a direct link from the row to their user record, or a path through another table (such as "this order's client is the current user"). Tables you leave unconfigured stay inaccessible to portal users unless you explicitly allow broader access for shared data.

Save changes in portal settings when you're done. You can return anytime to adjust which tables are included and how each one ties back to the logged-in user.

Best practices

Configure every table portal users need; unconfigured tables stay off-limits by default.
Prefer explicit links from each row to the relevant user (or a chain through a relation you trust).
Use shared “all users” access only for data that is safe for every portal user to read.
After changes, preview the portal as a test user to confirm they only see the right rows.