Permission Overview
Portal users only see the rows and fields they need. 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 or edit each field to the AI agent in the builder—it can set the users table, scope rows to the right portal user, and configure field-level view and edit access.
Example prompts for the AI agent
Scoped to the customer
Staff in a users table
Shared reference data
Protect sensitive fields
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.
Choose field access
Expand a table and choose whether each field is visible and editable. Edit access applies to both creating and updating records. If custom roles are configured, use the role selector to set a different field policy for each role.
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.