Notion Client Portal: What to Show, Where Records Live and Who Gets In

A Notion client portal is one page per client that shows that client's status, open requests, deliverables, files and invoices, pulled from databases you already keep. For most freelancers I'd build it on those databases and share each portal page with the client as a guest, because the client then reads the same records you update every day. Where the client-facing records live depends on your plan: on Free and Plus, keep each client's records inside their own portal; on Business and Enterprise, one set of master databases can serve every client through page-level access rules. Buy a template for layout ideas, publish to the web only what could be public, and look at a third-party portal tool only when clients won't use a Notion account.

A portal is three separate decisions: what the client sees, where those records live, and how the client gets in. Most template pages settle the first one and skip the other two, yet the second is where other clients' work gets exposed. A filtered view of a shared database hides other clients' rows from the screen, not from the client.

For a solo freelancer on Free or Plus, start with a guest-shared portal page that holds that client's own databases. For a studio on Business with many clients in one master database, add page-level access rules and keep a single set of records. For clients who won't create a Notion account, choose between a public page for material that isn't confidential and a portal tool that puts its own access control in front of Notion.

What should a client see on the portal page?

Lay the page out in the order a client asks questions: where are we, what do you need from me, what can I look at, and what do I owe. I'd keep it to seven blocks, top to bottom, each one fed by a database rather than by text you retype:

1. Status and next step. The current phase and the one next action, kept as two properties on the portal page itself so they sit at the top.
2. Waiting on you. Requests, approvals and missing material the client owes you, from a Requests database, filtered to a status option you name, such as “Waiting on client.”
3. Deliverables. Each draft or file up for review, with an approval status, from a Deliverables database.
4. Files and links. Brand assets, shared folders and reference material, from a Resources database.
5. Meeting notes. Agenda, decisions and action items from each call, from a Meetings database with a meeting template.
6. Invoices. Amount, due date and payment status, from an Invoices database. Keep rates and internal notes out of this database, or restrict them with property access on Business and Enterprise; hiding a property in one view changes only that view.
7. Request form. One form link for anything new, which lands as a record in the Requests database.

That selection follows what template makers put in, with two gaps worth closing. In the 35 complete listings readable in NotionApps' roundup of client portal templates, tasks or projects appear in 29 and invoices or payments in 15, while meeting notes appear in 5, deliverable handoff in 3 and “approve” or “approval” in only 2. If a template you're considering has no approval status and no meeting record, plan to add both.

The page shows records; deciding what counts as waiting on the client stays with you. Make it one status option you set on purpose, so the client's list never fills with items you simply haven't touched yet.

Where should the portal's records live?

This choice protects your other clients, and the safe answer depends on your plan. A portal page shows records through linked views, and Notion's help on data sources and linked databases says every linked data source “will respect the access level of the original database.” So a client who can't open the source database sees nothing in the linked view, and, without page-level rules, a client who can open it can open every record in it. Notion's sharing and permissions help adds that it “respects the broadest level of access given to a user,” which means a filter on the portal page decides what's displayed, not what the client is allowed to open. The guide to editing a linked database covers that difference in detail.

Free and Plus: each client's records inside their own portal

Without page-level rules, the safe structure puts the client-facing databases inside the portal itself: a Requests, Deliverables, Resources, Meetings and Invoices database for that client only, nested in their portal page. Share that page with the client, and no other client's records sit behind it. Notion VIP's client portal guide reaches the same fallback. It gives each client portal two top-level pages: a Data page that houses the master databases, a page the guide says “your client will never see,” and a Homepage of linked views. It then notes that the client needs access to the master databases to see those views, and that if this poses a privacy issue, “you'll need to create independent databases within client dashboards.” The same guide asks Notion for view-specific sharing; on Business and Enterprise, page-level rules on the source database now do a similar job record by record.

Your internal system stays where it is. Clients, Projects and internal Tasks can remain private master databases, as in the client project tracker; only the records a client should read move into their portal. The price is a harder overview: open requests sit in one database per client, so your weekly review needs a linked view of each client's Requests database instead of one filtered table. The weekly review dashboard shows how to lay out those panels, and once the list of per-client views gets long, that's the point to price Business.

Business and Enterprise: one set of master databases with page-level access

On Business and Enterprise, database page-level access lets one Requests database hold every client's requests and still show each client only the records assigned to them. The rule lives on the source: Notion's help says to open the database, which “must be the source database and not a linked view of it,” and that the rules “will apply across all views of your database. They'll also reflect in linked views of the database.” Its worked example is the portal pattern. Someone assigned to one task gets an error message if they visit the task database, yet works on that task, and on every task assigned to them later, through a linked view on a page you've shared with them.

That's the payoff of master databases: you update a request once and it's current on your dashboard and on the client's portal, and relations and rollups across clients keep working because every record sits in one place. Two conditions come with it. Page-level rules alone don't let the client add records, so Notion points to a form for new pages. And a broader grant anywhere else wins: Notion asks you to make sure anyone whose access you restrict this way “doesn't have greater access through another part of the Share menu.” For the person property, the rule itself and the check with two guest accounts, follow the client portal permissions guide.

Build the portal in five steps

Start with one client and one block, “Waiting on you,” and add the rest only once that block shows the right records from the client's side. One correct list is a better first portal than seven blocks you haven't checked.

1. Give the portals their own database. Create a small Client portals database with one page per client, rather than sharing the client's record in your Clients database. A Clients record tends to hold things a client shouldn't read, such as rates, lead source and notes, and property access, which controls which columns people can see and change, is a Business and Enterprise feature. On the master-database route, also give every Requests, Deliverables, Meetings and Invoices record a relation to the client plus the person property your page-level rule will use; relations and rollups walks through the relation.
2. Make one portal template. In the Client portals database, open the dropdown next to New and select + New template. Notion's database templates help says a template can contain “any type of content, including images, embeds, and sub-pages,” and that it “will show up identically on each page created with the template,” so set out the headings and the views or per-client databases once. Leave any relation in the template empty: a filled one makes every new page relate to the same existing page, which is why every new task links to the same client. On the master-database route, after you create a client's portal from it, point each linked view's filter at that client. On Free and Plus, create two portals and confirm that a request added in one doesn't appear in the other before you share either.
3. Put the status line in the page layout. Open the Client portals database as a full page, select •••, then Appearance & layout → Customize layout, and pin Phase and Next step in the Heading; you can pin up to 15 properties there. Notion's layouts help says a layout “will apply to all pages in the database,” so every portal opens the same way. You need at least Can edit access to the database, and the full builder runs on desktop or web.
4. Add the request form. A form can only be added to the original database that holds the records, so build it on the Requests database (on Free and Plus, the one inside that client's portal) and put its link on the portal. The share setting depends on the route, covered in the next sections; the client intake form guide has the full setup and follow-up.
5. Check the page as the client. Before sending the link, open the portal the way the client will, using the two-guest check in the permissions guide. On Business and Enterprise, the property access settings also have Preview, where you pick a person and see what permission a column would give them. If a block shows nothing for the client, Notion's FAQ on linked databases points to access on the original database first: on Free and Plus that's the client's own database inside the portal, and on Business and Enterprise it's the page-level rule on the source.

How should the client get in?

Pick the route by two questions: does the client have, or accept, a Notion account, and is anything on the page confidential? The table sets the four routes side by side. The setup steps for the first two are in the permissions guide, and the cost of guests versus members is in Notion guest vs member.

Guest invite is where I'd start for most freelancers, because the client sees exactly the page you shared and you can check it from their side before sending the link. Guests are added to individual pages, not to the whole workspace. Notion's pricing page lists 10 external guests on Free and unlimited guests on Plus, Business and Enterprise, and says guests are free of charge but can only access the individual pages they're invited to. Invite with an address outside your own domains: Notion's guide to adding members and guests says people on your organization's email domains are added as paid members, not guests, and a client who doesn't use Notion yet will need to sign up to open the page.

Guest plus page-level access is the upgrade once one master database serves several clients on Business. The client still enters through their portal page, but the records behind it come from the shared databases, limited by the rule rather than by the view. Notion notifies people by default when they're added to a person property a rule uses, so assign the client when the record is ready for them to see, not while it's still a draft.

A public link or Site fits material that could sit on the open web: a style guide, a process page, a welcome page. Notion's web publishing help lists what comes with that convenience. The page's metadata includes “the names, profile photos, and email addresses” of the Notion users who contributed to it, subpages are published by default unless you restrict them, and Notion's answer on password protection is no. A link shared as Anyone on the web with link can be set to expire under Link expires, and unpublishing a Site doesn't switch that link setting off, so remove it separately. A custom domain needs a paid plan and costs $8 a month per domain paid annually or $10 a month paid monthly, according to the pricing page.

A portal tool is the route when clients won't use Notion accounts and the material isn't public. Sotion's guide says its service can put a password on a client's top-level page that also protects the subpages nested in it, and serve the portal on your own domain. NotionApps, in the roundup above, describes a web app on a Notion backend with user-specific permissions and screens where clients submit requests and approve tasks. Those are the vendors' own descriptions of their products, and either way you add a second service to configure, keep running and trust with client data.

What can the client do from the portal?

Each thing you ask a client to do needs a minimum access level, and a mismatch shows up as a button that does nothing or a mention that reaches nobody. Match the action to the level before you design the block.

Approvals are where this matters most. I'd ask a client with Can comment to approve in a comment on the deliverable and change the status yourself, because the decision is theirs but keeping the record consistent is your job. Give Can edit content only if you want the client to set the status directly. On Business and Enterprise, property access can then leave one column at Can edit values only and keep the others at view, with rules on up to 20 properties. If a client reports a field missing, a client can't see a database property separates a column hidden by a view from one restricted by a rule.

Buttons need more care than they look. Notion's buttons help says a user must have Full access or Can edit permissions to interact with a button on a page, and a button that adds or edits a database page also needs the person clicking to be an editor of the target database. So an “Approve” button does nothing for a client who can only comment. Buttons are on all plans, but Send mail to and Send webhook need a paid plan, and Send Slack notification to needs Plus, Business or Enterprise. The buttons vs automations guide covers the choice when a status change should happen without anyone pressing anything.

Forms are the easier path for anything new. According to Notion's forms help, a guest can fill in a form shared as Anyone at {your workspace} with link only if they have access to the connected database. A per-client Requests database inside the portal gives them that, and the form can record who asked in a Respondent or Created by property. On the master-database route, sharing as Anyone on the web with link avoids opening the database at all, at the cost of anonymous responses. You can also choose to receive an email copy of each submission, which helps when requests arrive while you're out of Notion.

Keep the portal current without extra updates

A portal stays current when nothing on it needs a separate update. Every block is a view of records you already change as work moves, so the client's “Waiting on you” list grows when you set a request to the waiting status and shrinks when you move it on. Apart from the Phase and Next step properties, that's the whole upkeep for the core of the page.

For recurring touchpoints, a repeating database template in the Meetings database can create the weekly or monthly check-in page on a schedule; Notion's templates help lists daily, weekly, monthly and yearly repeats, and recurring tasks in Notion explains when a calendar repeat beats repeating after completion. Database automations come with paid plans: the pricing page lists “Basic buttons only” on Free and custom database automations from Plus up. Before you rely on one to move statuses, write its trigger, action and exception with the automations planning guide.

Two things break quietly. A synced block copied onto several portals can show nothing to a client who can't open its original, and a synced block not visible to a client traces it back. A client with Can edit on the portal page can also shift its layout by accident; the lock page vs lock database guide shows which lock fits. When the project ends, remove access with the offboarding steps in the permissions guide and keep a copy using the client project backup guide.

Should you buy a template or build your own?

Copy a template's layout and keep your own databases. A duplicated template brings its own databases, separate from the ones you already run, so you either move your records into it or keep two systems in step. Notion's client portal template category runs to more than 400 entries, and the 47 listings in the NotionApps roundup show how little the price tells you: 16 are free, and the 27 priced in US dollars run from $4 to $349 with a median of $27.

A template still leaves the hard parts to you: the relations to your client records, the access route and the form. The forms help warns that when you share a form from a template you duplicated, you should set up a separate version from scratch “so that all of your form responses go to you and not the original form's creator.” Buy one if you've never seen a finished portal and want a layout to copy; build from your tracker if your clients and projects already live in Notion. The templates for freelancers shortlist covers what to inspect before you pay.

Client portal setups, compared

There's no published benchmark for a client portal, so the comparable data is what template makers build in and what they charge. The counts below come from the NotionApps roundup dated June 20, 2025, a vendor list that includes NotionApps' own portal product. A listing counts toward a section when its name or feature bullets use a matching word, such as “invoice,” “payment,” “billing” or “finance” for invoices. The roundup announces 47 templates, and 35 have a complete feature list in the readable copy.

Read the two tables together. Tasks, communication and invoices are the sections template makers agree on. Meetings and deliverable handoff are rare, and only 9 of 35 listings mention feedback, approval or review at all, which is why the portal list above adds a deliverables block with an approval status and a meeting record. Prices cluster low, with about two-thirds of listings free or under $30, so the template fee rarely decides anything; the database work afterward does. What the counts don't show is quality: a word in a feature list says a section exists, not that it's connected to the rest of the template or safe to share.

Build on your own databases, one portal per client

For a freelancer on Free or Plus, I'd build a Client portals database, give each client a portal with their own Requests, Deliverables and Invoices inside it, and invite the client as a guest, because it's the structure where a filter mistake can't expose another client. On Business with many clients, move those records into master databases with page-level access rules on the source, since one record updated once beats a database per client. Keep public links and Sites for material that could be public, and pick a portal tool only when clients won't use a Notion account. Whichever route you take, start with “Waiting on you” for one client, check it from their side, and add the next block only after that.