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.
Should each client share one login?
No. Individual logins let you assign roles, remove access when people leave and see who did what.
Share data with clients, not between them
Start with Jet Admin for free and build a client portal with permissions enforced on your data.