How to share Notion with clients (and why it eventually breaks)

If you run an agency on Notion, you've already tried to share it with a client. Maybe more than once. There are four approaches that agencies cycle through, each with its own tradeoffs, and a structural limitation that catches up with all of them eventually.

This is a practical run-down: what each approach actually involves, when it works, and when it stops working. If you've been doing one of them for six months and feel the cracks, you're not imagining them.

The four approaches

Approach 1: Duplicate-database (the most common)

Maintain one internal Notion database for the team — with real estimates, scope notes, and the candid version of every client conversation — and a separate client-facing database that mirrors it. Update both whenever something changes. Use Zapier or Make to automate the sync where possible.

What it gets right: strong separation between internal and client conversations. The client never accidentally sees something they shouldn't because they're literally not in your workspace.

What breaks:

• Versions drift. The team updates one side; nobody updates the other. By week three, the two databases disagree about something important.
• The Zapier bill grows. Each new database property needs new automations; each new client needs duplicated automation paths. Most agencies we've talked to settle at $200–$400/month in sync automations.
• Client comments arrive in one database; team discussion happens in Slack; reconciliation happens in someone's head. There's no single source of truth for a single deliverable.
• The "polite version" of every task is your team's job to write. Every task that needs translating gets translated.

When to stop: when you spend more time keeping the two databases in lockstep than doing the work the client is paying you for. (That's roughly when, in our experience.)

Approach 2: Public-page share

Create a single Notion page per client (or one shared page across all clients), make it publicly accessible via Notion's "Share to web," and give the client a link. Everything on that page is visible to anyone with the URL.

What it gets right: zero maintenance for you. The client opens a URL, sees what you wrote, doesn't need a Notion account.

What breaks:

• It's a one-way broadcast. Clients can't comment, can't approve anything, can't submit requests — they read.
• The URL is public. If the link gets forwarded, anyone has access. "We'll just trust them not to share it" is not a security model.
• Everything on that page is visible. There's no notion of "this section is internal." You write the whole page in client-facing voice.
• Notion's public-page rendering strips features. Your linked databases may not render. Comments are gone. Live updates aren't pushed.

When to stop: the first time you need a client to do something (approve, comment, submit) — which is usually within the first two weeks.

Approach 3: Add the client as a guest

Notion's paid tiers let you invite "guest" users with limited access. The guest has a real Notion account; you add them to specific pages or databases; they can read and comment.

What it gets right: real two-way communication. Clients can comment. They can be tagged. They get notifications.

What breaks:

• Guests count against the per-guest allowance on lower tiers and against per-seat billing on higher tiers. An agency with 30 client contacts hits the limit fast and pays per-guest for the rest.
• Guests added to a database see the whole database. Not just their rows. You can't say "give this client only their rows" without a filtered view, and filtered views are a UI hide, not a permission boundary — a guest can navigate around them.
• Guests added to a page see the whole page, including linked databases the page references. If your project page links to your internal status database, the guest now sees that.
• Removing a guest is reactive — they had access until you noticed. Audit history of what they saw is thin.

When to stop: when you realize "guest" doesn't mean what you thought it meant.

Approach 4: Add the client to your workspace

Some agencies skip guest access entirely and add clients as full members of their Notion workspace, then rely on Notion's page-level permissions to control what each client sees. This is essentially "the workspace is the portal."

What it gets right: clients are first-class — they see everything you choose to share with them, comment freely, get notifications.

What breaks:

• Permissions are page-level, not row-level. If you share a database with a client, they see the whole database (including the columns and rows you forgot to hide).
• Cross-client leakage is a real risk. Page-level permissions are easy to set wrong, and the only way to validate them is to actually log in as each client and check.
• Per-user billing on full members is significantly more expensive than guest billing.
• Some of your team's internal pages will eventually link to client-facing pages. If a client has access to the linked page, they can navigate up.

When to stop: the first time a client accidentally sees something they shouldn't. (This is usually how agencies on this approach migrate off it.)

Why none of the four scales

All four approaches share a structural property: Notion's unit of visibility is the page or the database, not the task.

The agency-shaped problem is per-task. On any given deliverable, you have:

• An internal conversation about scope, estimates, and tradeoffs
• A client-facing conversation about the deliverable itself
• A decision the client needs to make (approve, request changes, decline)
• A history of how the deliverable evolved

Per-task visibility means a single task can carry the internal conversation in one thread and the client-facing conversation in another, with the engine enforcing which is which. Page-level or database-level visibility means you can't — you have to split the task into two, on two pages or two databases, and reconcile.

That's not a Notion limitation specifically. ClickUp's guests are workspace-level. Asana's are project-level. Trello's are board-level. The PM-tool category, as a whole, treats the project (or board, or page) as the visibility unit. Which means the agency tax — the constant reconciliation between internal and client surfaces — exists across all of them.

The structural fix

The fix is to push visibility down one more layer: from the page/board/project to the task and the comment.

When visibility is a column on the task itself, two things become possible:

1. One task carries both conversations. The team can argue internally about scope on a comment flagged Internal. The client can comment on the deliverable on a comment flagged Client. Both threads live on the same task; the database knows which is which.

2. The client portal is a different query, not a different page. Same data, same tasks — just filtered by visibility. There's no separate "client view" to maintain in sync with the team's view, because they're literally the same row, with the engine deciding which fields to expose.

This is what Workhouse does. The visibility flag is a column on the tasks table, with a CHECK constraint (internal or client). Portal queries include WHERE visibility = 'client'. The client physically cannot load internal rows — the application doesn't issue the query. A guessed URL returns a 404, not a 403, because as far as the portal's data layer is concerned, the row doesn't exist.

If you've been doing the Notion duplication dance for a while, the migration is straightforward: export your task databases as CSV, email us at migrate@workhouse.app, and we'll do the first migration during beta. The Notion alternative page has the step-by-step.

When to stay on Notion

Worth saying clearly: Notion is a brilliant tool. We use it for docs, knowledge base, internal wiki, and a lot of one-off lightweight databases. If your use case is "knowledge base for the team," "marketing site CMS," or "personal notes," Notion wins handily.

The specific friction this post addresses is "Notion as a project management tool for agencies running client work." If that's not you, none of this applies.

What to do today

If you're currently on one of the four approaches and the cracks are showing, three options:

1. Pick a better one of the four. The duplicate-database hack is the most stable of them, but most expensive in maintenance. Guest access is the cheapest but riskiest. Workspace membership is the most powerful but easiest to misconfigure. Public-page share is the least useful but lowest-overhead. None is great; some are less bad than others.

2. Add tooling on top of Notion to plug the gaps. Various third-party "Notion client portal" tools exist; we haven't found one we'd recommend, but the space is moving.

3. Move to a tool built for the agency-shape problem from the start. That's what Workhouse is. We'd say "obviously we recommend us" but we'll also point out that Basecamp's project-level model is honest, well-executed, and may fit some agencies fine if your engagements split cleanly into projects. See the full Notion alternatives list for the honest comparison.

The thing not to do is keep spending Friday afternoons reconciling two databases and assuming "this is just what agency work looks like." It's not. It's a specific category of friction that the right tool removes.