The structure behind a client portal that scales.
Most client portal templates fall over at the same point: they cannot show each client only their own data. The fix is in how the databases relate to each other — here is the structure that works.
- Two databases are essential: Clients and Members, with Members related to Clients.
- Every client-visible database needs a relation path back to Clients.
- One template plus a relation beats one duplicated template per client.
- Notion view filters control display, not access — they are not a privacy mechanism.
- Keep internal fields as separate properties so they can be hidden individually.
- If your workspace already matches this shape, Portalwith auto-detects and maps it.
The databases
One row per client company. This is the anchor every other database relates to. Name, primary contact, status, start date.
One row per person, each related to a client. This is what a login maps to — the email here is the email that signs in.
Related to Clients. Gives clients a place to see scope, milestones, and where things stand.
Related to Projects, and through them to Clients. Keep internal-only tasks flagged so they can be hidden.
Related to Clients. Amount, status, due date, and a link to the actual invoice.
Deliverables, Looms, Figma links. Related to Clients so nothing leaks across accounts.
Only the first two are required. Add the rest as your delivery process needs them.
Getting the properties right
Every client-visible database needs a path back to the Clients database. Filtering depends on it, and a missing relation is the single most common reason a portal shows the wrong rows.
Keep cost, margin, and internal notes as distinct properties rather than burying them in a shared text field. Property-level hiding only works if the data is separated.
Consistent select options render as clean badges and can be hidden individually. Free text cannot.
Client login matches on the member's email address, so that property has to be accurate and unique.
- •One database per client. It feels organised and becomes unmaintainable at ten clients — and no portal can filter across it.
- •Relying on a Notion view filter for privacy. Views control display, not access; anyone with the page can change them.
- •Mixing internal and client-facing rows in one database with no flag to tell them apart.
- •Storing the client name as text instead of a relation, which makes reliable filtering impossible.
Questions people ask
Plenty of free templates exist and most are a good starting structure. The limitation is not the template — it is that a Notion page shared publicly cannot show each client only their own rows, and cannot hide individual properties. The template gives you the data model; a portal layer gives you access control.
Two databases: Clients and Members, with Members related to Clients. Everything else — projects, tasks, invoices — is optional and can be added later, as long as each relates back to Clients.
No. Portalwith maps whatever structure you already have. If your workspace matches a known shape, setup is auto-detected; otherwise you map properties yourself in a few clicks.
Yes, and it should. One portal template plus a client relation means every client gets the same layout with their own data. Duplicating a template per client is the thing to avoid.
Already have the databases?
Connect them and Portalwith maps the structure for you — often automatically.
2-week free trial · No credit card · Notion-native