Fix QuickBooks Duplicate Customers by Email Domain
Fix QuickBooks duplicate customer email domain issues with Zapier Formatter and API-based lookup. Reduce duplicate records, failed receipts, and manual cleanup.
Notion Page Permissions: Spaces, Pages, Forms, Visibility
Notion page permissions are page-level, not block-level. Learn how spaces, sub-pages, locked pages, and forms work so you can share content safely.
TABLE OF CONTENTS
If you’ve ever tried to “hide just one section” of a Notion page from someone, you’ve run into the core rule of Notion page permissions:
Notion permissions are page-level, not block-level.
That one detail explains most of the confusion around spaces, sub-pages, databases, and forms. Here’s how to think about it, how locking changes editing behavior, and how to set up a clean internal vs external structure without creating a permission mess.
The short version (decision tree)
- Do you need someone to access only part of a page?
- You can’t hide individual blocks from someone who can view the page.
- Instead, put the sensitive content on a separate page and control access to that page.
- Do you need to collect info from someone outside your workspace?
- Use Notion Forms and share the form link.
- Keep the responses database private (internal), and add an automation for notifications.
- Do you need external partners to browse a library of documents?
- Create a dedicated external-facing space/teamspace, or a dedicated top-level “External Portal” page, and only link what you’re comfortable exposing.
Notion page permissions: the model that makes everything click
In Notion, nearly everything is a page:
- A regular document is a page.
- A database is a collection of pages.
- Every row in a database is also a page.
That means sharing is fundamentally about which pages someone can access, and what access level they have on those pages.
Access levels are attached to pages
When you share a page, you can typically grant one of these levels:
- Full access
- Can edit
- Can comment
- Can view
- No access
Those permissions apply to the page, and (usually) cascade to content inside it unless you explicitly override permissions on a sub-page.
What you can’t do: block-level visibility
You can’t have a single Notion page where:
- A partner sees Section A
- Staff sees Section A + Section B
- Both are on the same page, with Section B hidden from the partner
If the partner can view the page, they can view the blocks on that page.
Workaround: split the sensitive section into a separate page, then:
- link to it for staff
- do not grant access to partners
Page vs sub-page: what “permission cascade” really means
Notion is hierarchical:
- Teamspace / top-level pages
- Pages
- Sub-pages
- Databases
- Database rows (pages)
When someone clicks a link to a page they don’t have access to, they’ll typically see a “no access” message. They won’t be able to open it, even if they can see the link text.
Best practice: give someone access to the minimum set of pages needed to navigate, then grant deeper edit access only where needed.
Locked pages: what locking does (and doesn’t do)
Locking is a safety rail, not a security layer.
- Locking prevents accidental edits for people who already have permission to edit.
- Locking does not grant or revoke access.
- Anyone with edit access can select “Unlock for me,” make changes, and Notion re-locks the page when they’re done (as of October 2026).
Practical pattern:
- Use locking for “reference” pages where you want to prevent accidental changes.
- Use permissions to control who can edit.
Full width setting and locked pages
Full width is a page setting, not a per-user preference. If you set a page to Full width and then lock it, everyone who opens the page sees that layout.
Groups, spaces, and external partners: patterns that work
Pattern 1: Internal workspace + External partner teamspace
Use this when partners need a lot of navigation freedom, but you want a clean wall between internal and external content. Partners usually join as guests, so it’s worth knowing how to share Notion databases with guests without paying for member seats.
- Internal teamspaces: staff-only work (drafts, HR, internal ops)
- External teamspace: only partner-facing docs, policies, deliverables, and forms
This pattern is the easiest to reason about because permissions are consistent within each teamspace.
Pattern 2: External portal page inside the internal workspace
Use this when you want partners to see a curated collection, but you don’t want to stand up a full separate space.
Create a top-level page called something like “Partner Portal” and only add:
- links to the pages partners should see
- linked database views that only show partner-appropriate items
If your internal pages are deeply nested, do not simply share the internal parent page. Start at a portal page and share outward deliberately.
Notion Forms: public submission, private responses
Notion Forms work well when you want people to submit information without giving them access to your internal system.
Here’s the key: forms submit into a database. Submissions show up as new rows (pages) in that database.
Share settings for forms
You can share a form publicly while keeping responses private.
Typical setup:
- Who can fill out: “Anyone on the web with link” (or “Anyone at your workspace with link” for internal-only forms)
- Responses database: internal-only
Notifications for new submissions
A Notion form won’t alert your team about new submissions outside Notion on its own. The common pattern is a Notion database automation (paid plans, as of October 2026):
- Trigger: when a new page is added to the responses database (new form submission)
- Action: send a Slack notification, send an email from a connected Gmail account, or send a webhook to Zapier or Make
That gets you the same “new submission” experience teams expect from Google Forms.
Common gotchas (and how to avoid them)
- Gotcha: “They can’t see a sub-page even though I shared the top page.”
- Gotcha: “We removed someone’s access and now we can’t find the page.”
- Gotcha: “We want them to edit just one thing.”
Permissions may not be inherited the way you expect, especially if something was overridden deeper in the tree. Confirm access on the exact page.
If you restrict a page too aggressively, even admins can lose visibility depending on settings. Before changing permissions broadly, ensure you’re in an admin group that retains access.
Create a dedicated page (or a dedicated database row) for the thing they should edit. Share that page with edit access, and keep everything else view-only.
Quick recommended setup (most teams)
If you’re starting from scratch and want a durable structure:
- Create groups by job function (Admins, HR, Program Staff, Contractors, Partners).
- Keep internal operational content in internal teamspaces.
- For partners, either:
- create an external teamspace, or
- create an external portal page and share only that page tree.
- Use Notion Forms for intake, and automations for notifications.
- Use locks to prevent accidental edits, not as permission control.
Get help setting up Notion page permissions
Permission setups usually break when someone shares an internal parent page to fix one access request, and partners suddenly see everything underneath it. If you want a clean internal/external structure, book a ZoomFlow session. One of our Notion consultants will map your teamspaces, portal pages, and forms with you live on the call.
Related Posts
Client reschedule workflow (portal + email) for service calls
Build a client reschedule workflow that emails a rebooking link, cancels the original booking, returns credit, and logs an audit trail for service calls.
Automate monthly Salesforce exports from S3 + Google Sheets
Automate monthly Salesforce exports from S3 + Google Sheets: pull daily files from S3, calculate member status in Sheets, and generate a weekly CSV in Drive.
