Security & permissions

Your clients trust you with their business. Here is exactly how PortalTable keeps one client's work away from another's — and what it does not do yet.

Per-client data scoping

A client's portal is bound to one access grant, and that grant names one client in one workspace. Every read the portal makes is filtered by it in the query itself — the browser is never sent rows it then hides, because there is no client-side filtering to bypass.

The database enforces the same ownership independently: a project's workspace must match its client's, and a task's must match its project's, as foreign keys. So a bug in the application cannot produce a row that belongs to the wrong client — the write would be rejected.

Your tables aren't reachable from a browser at all. Every read and write goes through the server with a key that never leaves it, so there is no public database endpoint for anyone to probe.

Check the portal before going live

Use Preview as client and confirm you see only that client's records, and only the files you meant to share. Preview renders through exactly the same scoping the live portal uses, so what you see there is what they get.

Roles and permissions

Two separate questions: what a *client* can do in their portal, and what a *teammate* can do in your console.

Client — view: Signs in to one portal and reads their own projects, approvals, invoices, and shared files. Cannot act on anything.
Client — approve: The same, plus approving or requesting changes on their own reviews. Never sees the console.
Owner: Full control: workspace, billing, team, branding. Usually the agency principal.
Admin: Everything except billing and minting other admins.
Member: Works on client delivery — clients, projects, tasks, invoices, approvals — but cannot touch the team, billing, branding, or the subdomain.

Revoking is immediate

Every portal request re-checks the grant, so revoking a client's access takes effect on their very next click. An existing session doesn't outlive a revoke, and neither does locking a workspace.

Authentication

Clients sign in with a magic link sent to the exact address you invited — no password to set or reuse, and a link addressed to someone else won't open their portal. You sign in to the console with Google or with a password of your own.

Encrypted in transit and at rest

Every portal is served over HTTPS only. Data at rest is encrypted by Supabase, our database host, on AWS infrastructure.

Decisions are on the record

Each approval carries its outcome, the client's note, and when they decided. A full audit log covering edits and sign-ins is coming on Studio.

Pre-launch checklist

Before flipping a portal to Live, run through these:

1
Scope verified
Preview as client shows only that client's records — nothing from another account.
2
Nothing internal exposed
No internal details (margins, rates, private notes) appear anywhere client-visible. Check tasks and files in particular.
3
Access level set
The client has view or approve, whichever you meant. Approve lets them sign work off.
4
Invite goes to the right address
The magic link only works for the address on the grant, so a typo means they can't get in — check it before you send.

In the EU (Frankfurt), on Supabase. A choice of region per workspace isn't offered yet — if you need US or another region, tell us and it will weigh on where we take this.

No, and we won't imply otherwise. PortalTable is early — a solo studio building in the open, on infrastructure (Supabase, AWS, Vercel) that carries its own certifications. If your client's procurement requires SOC 2 from us today, we're not the right fit yet. We can sign a DPA.

Yes. Revoke the grant or pause the portal and their next request is rejected — sessions don't outlive a revoke.

Billing & plans

What each plan includes.

How PortalTable works

Revisit the big picture.