You can give a client access to their Notion portal without sharing every client’s records. Share a dedicated portal page with that person as a guest, then grant access only to the pages they need. On Business and Enterprise, database page-level rules can grant access through a Person or Created by property across a shared master database.
I recommend starting with a separate page for a small delivery portal. Use a master database when central reporting matters and you can maintain its access assignments. Either way, a filtered view or a column hidden with Property visibility is a presentation choice. The permission settings must enforce the client boundary.
Choose the access model before building the portal
| Portal model | Permission responsibility |
|---|---|
| Separate client page, with its own approved subpages or database | Share only that client’s container and check its descendants. This avoids depending on database page-level rules, but each client’s structure needs maintenance. |
| Private master database, with linked views in client portal pages | Use database page-level access on Business or Enterprise. Assign the right people to each record and remove broader grants that would expose the rest of the database. |
A shared master database is useful when you need to manage all projects together. A separate database per client is a reasonable alternative on a plan without page-level rules. Keep the datasets separate; adding a filtered linked view of one broadly shared database does not achieve the same isolation.
Define the client-facing content before granting access. For example, a deliverable page might contain the approved brief and client feedback. Put your internal pricing margin and private discussion on a separately permissioned page. Notion’s Property visibility setting hides or shows properties in a database view; do not rely on it to protect confidential information within a page the client can access.
Share the portal page with the right guest
Create one portal page for the client, outside any parent page you intend to share with other clients. Keep your internal workspace navigation out of its content. Then use Notion’s guest invitation controls:
- Open the portal page and select Share.
- Review General access. For a private client portal, choose Only people invited and review the people already listed.
- Enter the client’s email address and select the permission level they need.
- Confirm that the invitation will add the person as a guest, then select Invite.
An invited guest needs their own Notion account. Workspace guest limits and security settings can affect the invitation, so check the person’s role instead of assuming every email invitation creates a guest. If the role is unclear, resolve it before sharing sensitive content; the guest-versus-member guide explains that separate decision.
Pick the lowest permission that supports the client’s task. Notion’s access-level definitions distinguish feedback, editing, and sharing rights:
| Level | Use it for |
|---|---|
| Can view | Reading progress and approved deliverables. |
| Can comment | Leaving feedback without changing the page content. |
| Can edit | Changing content on that page, when the workflow requires it. |
| Full access | Editing and sharing the page with others. I would reserve this for someone responsible for managing its access. |
A client may need comment access to the portal and edit access to a particular submission page. Choose those grants separately. Giving edit access to the landing page is not necessary merely because one deliverable needs editing.
Configure access to records in the master database
For the master-database model, keep the source database unshared with clients through ordinary database, parent, workspace, or teamspace grants. You will grant access to selected records instead. A rule can add access; it cannot cancel a broader grant the person already has.
Use a dedicated Person property such as Client access. A client name in a Select property or an email address in an Email property is not the property used by this permission rule. Notion documents rules for Person and Created by properties.
- Open the source database, not a linked view in the portal.
- Add a Person property for access assignments, if you do not already have an appropriate one.
- Select Share. Under Page-level access, select Add a new rule.
- Select the Person property, choose the required access level, and select Create rule. Start with Can view or Can comment for client updates and feedback.
- Put the client’s actual guest account in that property on every record they should receive. Leave other clients’ records unassigned to that guest.
A property can contain more than one person. In an example with two client contacts, add both only to the records both should receive. Keep access assignments separate from an internal Assignee property when the person doing the work and the person allowed to read it are different.
Assign each client to their records
Set up example assignments before entering real data. In this fictional example, Alex is Client A’s invited guest account and Blair is Client B’s. The rule grants Can comment through Client access; the source database has no ordinary client grant, and there are no broader or direct record shares.
| Record | Client access — Person | Expected client access from this rule |
|---|---|---|
| A delivery brief | Alex (Client A) | Alex can open and comment; Blair gets no grant. |
| B delivery brief | Blair (Client B) | Blair can open and comment; Alex gets no grant. |
| Internal planning | Empty | Neither guest gets access from this rule. |
Select the real guest account in the Person field, not a text label that resembles its name. In this setup, the people selected in Client access determine access; the record’s Client name does not. If both contacts should receive a record, add both intentionally and include that record in both guests’ checks.
Keep clients from editing the access assignment
Keep the access assignment under internal control before granting Can edit to a record. Business and Enterprise include Property access controls for individual columns.
- With Full access to the original database, open its table view on web or desktop.
- Open the Client access column menu and select Property access.
- Choose No access as the default, or Can view property & values if clients need to see the assignment.
- Add an exception for the internal people who maintain assignments, with Can edit values only.
- Use Preview for each intended client, then save the rule.
These controls need their own permission review. People with Full access to the database bypass column rules, and matching exceptions use the least restrictive access. Review the Share menu and every exception, then check that a guest with record-editing rights cannot change Client access. Property visibility in a view is still insufficient protection. If the configuration cannot preserve the intended assignments, use a separate client dataset or a submission form instead.
Property access is configured on web or desktop, with saved rules still applying on mobile. It is unavailable in wiki databases. A view that filters, sorts, or groups by a column the client cannot see may not open for them. Build the portal view around fields the client is permitted to use rather than a hidden Client access column.
Repeat the rule and assignments for each relevant data source, such as tasks and documents. Notion allows each data source in a database to have its own page-level rules. A rule on Tasks does not automatically configure Documents.
Add the permitted records to the portal
Next, open the client’s portal page, type /linked, select Linked view of data source, and choose the source database. Add useful filters for the client’s active work. Notion’s documented linked-view pattern for a person without database access lets that person work with permitted records from a shared page even though opening the source database itself produces an access error.
The page-level rules apply across views and linked views. Filters can narrow the displayed list further; access to another client’s record must remain blocked when a filter changes. The source database’s permission rules remain the access control.
Allow new submissions without opening every record
Access to existing records and permission to create new ones are separate choices. Notion’s Can create permission on Business and Enterprise permits new database pages without allowing someone to view or edit existing pages they have not individually been granted. Configure the intended access to submitted pages too; creation permission does not settle who should later read or edit them.
Do not give a client Can edit content on the whole database merely to let them submit a request. That database permission allows creating and editing its pages and property values while protecting the database structure. Protecting the schema is a different requirement from keeping clients’ records separate.
A form is another submission route. In Share form → Who can fill out, a form can be available to the workspace or to Anyone on the web with link. Notion’s form-sharing conditions say that guests need access to the connected database to use a workspace-only form, and public-link respondents are automatically anonymous. Do not treat an email answer on a public form as authenticated guest identity.
Keep public intake limited to information you are prepared to collect through that link. The Access to submission setting is available when the form is workspace-only and anonymous responses are turned off. Check who can submit responses separately from who can access the response database.
Review inheritance and broader grants
Notion follows the broadest access level granted to a person. If a client has Can view through a record rule but can already read the whole database through another share, the rule does not hide the other records. Remove the unwanted broader grant before relying on the rule.
Check the Share menu on the portal, its parent pages, and every source database. Subpages inherit their parent’s permissions when created. Then review explicit shares on individual records, because an old direct invitation can survive a change to the surrounding structure.
Check General access and the Publish tab separately. Anyone on the web with link permits access by people outside the workspace, including visitors without a Notion account. Turning off search-engine indexing or using an obscure URL does not turn a public page into an invited-guest portal.
Review relations and linked pages as routes the client can follow. Notion’s relation display settings can show properties from related pages, so inspect the information displayed on the allowed page as well as permission to open the destination. Keep private comments and internal attachments off client-facing pages.
Check the portal as two distinct guests
Your owner account has too much access to demonstrate the client restriction. Before using real client information, create fictional Client A and Client B records and check the portal with separate guest identities. The outcomes below are requirements for that example, not reported test results. In the example above, Alex is Client A’s guest and Blair is Client B’s.
| Check | Client A | Client B |
|---|---|---|
| Own portal and assigned records | A content opens | B content opens |
| Copied URL to the other client’s record | B content denied | A content denied |
| Source database in the master-database model | Database denied; assigned rows remain usable through the portal | Database denied; assigned rows remain usable through the portal |
| Properties, relations, comments, and attachments on an allowed record | Only information approved for A | Only information approved for B |
| Client access assignment on a record the client can edit | Assignment read-only or inaccessible | Assignment read-only or inaccessible |
| Search, breadcrumbs, and links from the portal | No access to B or internal pages | No access to A or internal pages |
| Feedback or submission action | Required action works; unrelated records remain denied | Required action works; unrelated records remain denied |
Record the account used, the exact page URL, the intended outcome, and the actual outcome. Investigate an unexpected title or property even if the destination page will not open. A denied destination does not make private information already displayed on the portal acceptable.
When a guest check fails, correct the specific grant
Use the actual account and record from the failed check. Notion’s page-level rules add access through the selected property; its property-access troubleshooting distinguishes wider grants from views using inaccessible columns.
| Failure | Inspect | Action and expected change |
|---|---|---|
| Own assigned record will not open | Signed-in guest identity, Person assignment, selected property/rule, and correct data source. | Correct the missing or wrong intended grant. The record should open through the portal while the source database remains denied. |
| Another client’s record opens | Direct record shares, parent/workspace/database grants, public links, and unintended Person assignments. | Remove the unintended access path, then repeat both guests’ direct-link checks. Narrowing a filter is not the fix. |
| The permitted record opens, but its portal view does not | Whether Filter, Sort, or Group uses a column the guest cannot see. | Use a view based on permitted fields. Keep the protected assignment column restricted and confirm the permitted view opens. |
| A guest can edit Client access | Full access grants, column default, matching exceptions, and Preview for that guest. | Correct the assignment-control permissions or use the separate-data fallback; recheck that the guest can perform their task without changing access assignments. |
Stop the handoff while an unrelated record or internal information remains exposed. Fix one identified path, then repeat the affected checks; a successful owner view is not a replacement for the guest’s result.
Repeat the relevant checks after adding a data source, changing an access property or permission rule, or moving pages under a different parent. Review a new client’s portal before sending its link; a correct previous portal does not establish that the new assignments are correct.
Remove access at the end of the project
For a direct page invitation, open Share, use the dropdown beside the person, and select Remove. That does not cancel access supplied by a database rule. For the Person-property setup above, remove the departing guest from Client access on the relevant records and review other direct grants.
If you chose a Created by rule instead, its value is automatically recorded and not editable. Do not plan offboarding around clearing that property, or delete a shared rule without considering everyone it affects. Use workspace guest removal when the client should lose all access.
Moving a parent page into Private is also incomplete offboarding: Notion notes that subpage permissions remain unchanged.
If the client should leave the workspace entirely, a workspace owner or membership admin can remove the guest in Settings → People or Members → Guests, depending on the plan. Notion documents that workspace removal procedure separately from removing one page invitation.
Close any public page or form links that are no longer needed, then check saved portal and record URLs from the removed guest’s account in a fresh session. Keep a short access record showing the removal date and any deliberately retained pages. Revoking Notion access cannot recall information the client has already downloaded or copied.
