Back to Blog
Tutorial
Aug 12, 20268 min read

How to Share a Notion Database With Clients (Without Giving Them Workspace Access)

Sharing a Notion database with a client usually means over-sharing. Here are the four real options, what each exposes, and how to show one client their rows and nobody else's.

Share:

You have a Tasks database with every client's work in it. One client asks for visibility. The obvious moves — invite them as a guest, or publish the page to the web — both do more than you want.

Here is what each option actually exposes, and what to do instead.

Option 1: Invite them as a guest

Notion guests get access to a specific page and everything nested under it. That works when the content is genuinely theirs alone.

What this exposes

  • Every row in the database, unless you build a separate filtered database per client
  • All properties, including cost, margin, and internal notes
  • The comment history, which often contains internal discussion
  • Your workspace name and member list in the sidebar

The filter trap

A view filter is not a permission. If you share a database and filter it to one client, that client can change the filter, or switch to another view, and see everything. Views control display, not access.

Guest access also costs a seat on most plans once you pass the free guest allowance, which gets expensive as your client list grows.

Option 2: Publish to the web

Publishing removes the login problem by removing the login. Anyone with the URL sees the page, and search engines can index it unless you disable that.

For a public roadmap or help doc this is exactly right. For anything client-specific it means one client can send the link to another, and there is no way to revoke a single person's access.

Option 3: Duplicate a database per client

This is the most common workaround and it works fine for two or three clients. The problems arrive gradually.

Where it breaks down

  • Schema changes have to be repeated in every copy, and they drift
  • Rollups and cross-client reporting stop working, because there is no single table
  • Onboarding a new client means duplicating and rewiring, not adding a row
  • Nobody can answer 'how many open tasks across all clients' without manual work

If you already have five or more duplicated databases, that is usually the signal it is time for a different approach.

Option 4: Keep one database, filter per client

The structure that scales keeps a single Tasks database and adds a relation property pointing at a Clients database. Every row is tagged with the client it belongs to. Nothing is duplicated.

That relation is what makes real filtering possible: instead of hoping a client does not change a view, the system resolves which rows that specific signed-in person is allowed to see, and never sends the rest.

  • A Clients database with one row per client company
  • A Members database with one row per person, related to Clients, holding the email they sign in with
  • A relation from every client-visible database back to Clients
  • Internal fields kept as separate properties so they can be hidden individually

Why the email property matters

Login matches on the member's email address. If that property is inconsistent or duplicated across rows, people end up seeing the wrong data or nothing at all. It is worth auditing before you invite anyone.

Comparing the four

ApproachPer-client dataHide fieldsRevoke one personScales past ~5 clients
Guest inviteNoNoYesCostly
Publish to webNoNoNoNot applicable
Database per clientYesManuallyYesPoorly
One database + relationYesPer propertyYesYes

What clients actually see

With the fourth approach, a client opens a link on your domain, enters their email, and clicks a magic link. They land on a page showing their projects, their invoices, their tasks — rendered as a normal web app rather than a Notion page.

They never see your workspace, your other clients, or the properties you chose to hide. You keep working in Notion exactly as before, and changes appear on their side without a publishing step.

Can I share just one Notion database view with a client?

You can share a page containing a view, but the client can modify or switch views and see the full database. Views are a display convenience, not a permission boundary, so this should not be relied on for anything confidential.

Do guests count toward my Notion plan seats?

Notion plans include a limited number of guests, after which you need to upgrade. The exact allowance depends on your plan, so check Notion's current pricing before planning around guest access for a growing client list.

Can a client edit data if I share it this way?

It depends on what you allow. Read-only is the default for most client portals, but you can permit comments, approvals, or form submissions on specific databases where two-way interaction is useful.

What if my database does not have a client relation yet?

Adding one is usually the only structural change you need. Create a Clients database, add a relation property to your existing tables, and populate it. It is a one-time tidy-up that unlocks everything else.

Show each client only their rows

Portalwith reads your existing Notion databases, filters them per client, and puts a branded login in front. Your workspace stays private.