How to Scope Notion Data Per Client (Filters vs Identity)
“Scope the database to each client” is the sentence every Notion-for-agencies setup guide uses. It usually means: add a Client property, filter the linked view, share the page. That is a good internal dashboard. It is not authorization. This post is only about that distinction — not how to design a portal template, and not how to invite guests.
What “scoped” has to mean
For multi-client work, scoped means: given this logged-in identity, the system is incapable of returning another client’s rows, even if the person tampers with the UI, guesses a page ID, or follows a relation. If a motivated viewer can clear a filter and see the rest of the database, the data was never scoped. It was sorted.
Four ways agencies try to scope Notion
| Approach | Who enforces it | Can the client bypass it? | Scales to many clients? |
|---|---|---|---|
| Filter on a shared linked view | The view (UX) | Often yes — change filter, open source DB, follow relations | Easy to create, unsafe to share |
| Duplicate a database (or page tree) per client | Separate pages + guest invites | No, if you never share the others | Ops tax: every schema change × N copies |
| Page / database permissions per record | Notion ACL | If inheritance or linked views are wrong | Does not scale operationally past a handful |
| Server-side identity scoping | API/backend before render | No — unauthorized rows are never sent | One shared DB; N client logins |
Why a Notion filter cannot be the security boundary
Filters run in the client UI against data the viewer is already allowed to load. Share the database (or a page that embeds it) and you have granted database access. The filter only chooses a default slice. Linked views, relation properties, and “open source” affordances are how leaks happen in real agencies — not Hollywood attackers, just a curious client or a forwarded workspace.
That is why Portalize vs Notion sharing and Notion permissions for client work keep repeating the same sentence: page access is not row-level security. This post is the “then what do I do in the data model?” half.
Page-level permissions vs a portal layer, with inheritance and linked databases spelled out.
Notion permissions for client workWhen duplication is the honest answer
If you have two clients, no shared schema, and you will never need a rollup across the roster, a duplicated page tree plus guests can be fine. The failure is linear: every property rename, every new status option, every template tweak becomes N edits. Duplication also burns guest seats. Use it as a prototype, not as the model you take to twenty accounts.
What server-side identity scoping looks like
Keep one Projects/Tasks/Files database. Store a stable client identity (relation, email, or unique id) on each row. When a client logs in, the portal backend loads only rows that match that identity, then applies field-level visibility for the view. The browser never receives the other clients’ JSON. Optional write-back re-checks the same ownership rule before Notion is updated.
- One workspace; no per-client duplicate databases required.
- Clients do not get Notion accounts or guest seats.
- Changing a filter in a hypothetical Notion UI would not matter — they are not in Notion.
Portalize is that layer: connect Notion, map client identity, define views, invite with magic links. Templates ship with live previews so you can see the scoped shape before you connect a workspace.
Scope each client on the server — start free with up to 3 clients, no credit card.
Start freeRelated
The failure-mode table across public pages, guests, filters, and portals is Client portal vs shared Notion page. The agency product angle is Notion client portal for agencies. Browse templates if you want a concrete view layout first.
See live portal templates with per-client views already mapped.
Browse templates