Client Portal Permissions: How to Set Them Up Right

Client portal permissions decide which records each person can see and what they can do with them. The core rule is simple: every client sees only their own data. Getting it right takes more than hiding rows in the interface. Permissions have to be enforced on the data itself, account by account, role by role, including the people inside your own team.

The three layers of portal permissions

1. Tenant scoping: which client

Every record belongs to a client account (a tenant), and every portal user belongs to one account. All queries are filtered by that account automatically. This is the layer that prevents cross-client leaks.

2. Roles inside a client: who at the client

A client's finance lead should see invoices; a project contributor may not. Common roles are client admin, client member and client viewer.

3. Internal roles: who on your team

Account managers see their clients, support sees tickets, finance sees billing, and admins configure the portal.

How to set up client portal permissions

Step 1: Add a client ID to every table

Projects, documents, invoices, tickets and users each carry a client account ID. Records without one should not be visible in the portal.

Step 2: Enforce the filter on the server

Apply "client ID = current user's client ID" in the data query or the platform's permission rules, not as a visual filter a user could remove. If your database supports row-level security, such as PostgreSQL RLS, it adds a second layer.

Step 3: Define client roles

Role	View	Create/edit	Manage
Client admin	All account records, invoices	Requests, approvals, uploads	Invite and remove users
Client member	Records they are assigned to	Comments, uploads, requests	None
Client viewer	Shared reports and documents	None	None

Step 4: Restrict fields, not just rows

Hide internal notes, margins, cost prices and staff-only statuses from portal users even on records they can see.

Step 5: Secure actions

Check permissions on every action, such as approve, upload, pay or delete, on the server. A hidden button is not a permission.

Step 6: Handle files

Uploaded files inherit the permissions of the record they belong to. Avoid public file links; use expiring, authenticated URLs.

Step 7: Set up internal access

Limit account managers to their own clients, and log when staff view client records.

Step 8: Test for leaks

Create two test clients and try to reach one's data as the other: change IDs in URLs, call the API directly, search globally and open shared file links. Repeat after every major change.

Common permission mistakes

Filtering by client in the interface only.
Guessable record IDs in URLs with no server-side check.
Public file links that never expire.
One shared login per client company.
Internal notes stored in fields visible to clients.
Forgetting to remove access when a client contact leaves.

Client portal permissions checklist

Every table has a client ID, and every portal query filters by it on the server.
Client roles are defined and assigned per user.
Sensitive fields are hidden from portal roles.
Actions are authorized on the server.
Files are private and linked to records.
Staff access is scoped and logged.
Leak tests pass for two test clients.
Offboarding removes portal access.

Build a permission-safe portal with Jet Admin

Jet Admin builds client portals on your existing data, across 200+ integrations queried in place. External users sign in and see only their own rows, with scoping enforced by the platform rather than the page layout. Roles can be set inside each client account and for your internal team, down to fields and actions. SSO, granular permissions and audit logs are on the Business plan and above, and unlimited users on every plan keeps costs flat as you add clients. See client portal templates to start from a layout, or our guide to client portal design.

Frequently asked questions

How do I make sure clients only see their own data?

Tag every record with a client ID and enforce a server-side filter on every query, file and action, then test by trying to access one test client's data as another.

What roles should a client portal have?

Usually client admin, client member and client viewer on the client side, plus account manager, support, finance and admin on your side.

Is row-level security needed for a client portal?

It is strongly recommended. Whether through the database or the portal platform, permissions must be enforced on data, not just the interface.

No. Individual logins let you assign roles, remove access when people leave and see who did what.

Start with Jet Admin for free and build a client portal with permissions enforced on your data.