You may have noticed that when you share a parent page with a guest, some of its sub-pages automatically get the same permissions while others remain private or inherit a different access level. This behavior is not random. It depends on the type of page, the sharing method you used, and the page’s position in the workspace hierarchy. In this article, you will learn the exact rules that govern sub-page permission inheritance in Notion and how to predict or control which sub-pages inherit permissions.
Key Takeaways: How Sub-Page Permissions Are Inherited in Notion
- Share menu > Add people > Can edit / Can view / Can comment: When you add a person to a parent page using the Share menu, that person automatically gains the same permission level on all sub-pages that are not already shared with someone else.
- Share menu > Copy link > Share to web: Making a parent page public to the web also makes all sub-pages public, regardless of their individual share settings.
- Share menu > Add people > Invite as guest: Inviting a guest to a parent page gives that guest access to all sub-pages that are not explicitly shared with a different set of people.
- Database item pages (inside a database): Sub-pages created inside a database inherit permissions from the database itself, not from the individual item’s parent page.
How Notion Permission Inheritance Works for Sub-Pages
Notion uses a cascading permission model for pages that are nested as sub-pages. When you share a parent page with a person or a group, that permission level is automatically applied to all sub-pages that exist directly under the parent. However, if a sub-page has its own explicit share settings — for example, you manually added a different person to that sub-page — the inheritance stops at that sub-page. The sub-page then uses its own permission list, and the parent’s permissions do not override it.
The key rule is: permissions cascade down unless a sub-page has its own explicit permissions. This rule applies to both workspace members and guests. A sub-page that has never been shared explicitly will inherit the parent’s permissions. A sub-page that has at least one person or group added through its own Share menu will ignore the parent’s permissions for that specific access list.
There are three main scenarios where sub-pages inherit different permissions:
Scenario 1: Sub-Page Has Its Own Explicit Share Settings
If you manually open a sub-page and add a person using the Share menu, that sub-page now has its own permission set. Even if the parent page later gets a new shared user, that user will not be added to the sub-page. The sub-page is now “locked” to its own list. This is the most common reason why a sub-page inherits different permissions: it was intentionally shared separately.
Scenario 2: Sub-Page Is Inside a Database
When you create a sub-page inside a database — for example, you open a database item and create a new page inside it — that sub-page inherits permissions from the database itself, not from the item’s parent page. The database is the direct parent of all items inside it. Therefore, sharing the database with a person gives that person access to all items and their sub-pages, unless an item has its own explicit permissions.
Scenario 3: Sub-Page Is a Linked Database or a Database View
A linked database is a view of an existing database. It does not contain its own data. Permissions for a linked database view are inherited from the source database. If you share the parent page that contains the linked database, the person sees the linked database only if they already have access to the source database. Otherwise, the linked database appears empty or shows a permission error. This can make it look like the sub-page inherited different permissions when in fact the permission is controlled by the source database.
Steps to Check and Control Sub-Page Permissions
Use the following steps to inspect which sub-pages inherit permissions from a parent page and to change that behavior.
- Open the parent page’s Share menu
Click the Share button in the top-right corner of the parent page. The Share menu shows all people and groups who have access to this page. - Check whether a sub-page has its own permissions
Navigate to the sub-page you want to inspect. Click its Share button. If the Share menu shows a message like “This page is shared with [number] people” and lists people not on the parent page, the sub-page has its own permissions. If it says “This page inherits permissions from [parent page name],” it inherits. - Remove explicit permissions from a sub-page to force inheritance
Inside the sub-page’s Share menu, click the three-dot icon next to each person or group and select Remove. After removing all explicit permissions, the sub-page will inherit permissions from its parent page again. - Add a person to a sub-page to stop inheritance
If you want a sub-page to not inherit from its parent, add at least one person or group to that sub-page through its Share menu. The sub-page will now use its own permission list. - Check database sub-pages separately
For sub-pages inside a database, open the database itself and click its Share button. The database’s permissions apply to all items and their sub-pages. To make a single database item private, open that item and add or remove people from its Share menu.
If Sub-Page Permissions Still Behave Unexpectedly
Sub-page shows “You don’t have access” even though the parent page is shared with you
This usually means the sub-page has its own explicit permissions that do not include you. Ask the page owner to check the sub-page’s Share menu and add you. Alternatively, if the sub-page is inside a database, the database itself may have different permissions than the parent page.
Linked database sub-page appears empty
A linked database sub-page shows data only if the viewer already has access to the source database. If you shared the parent page with a guest but the source database is not shared with that guest, the linked database appears empty. Share the source database with the guest to fix this.
Guest sees some sub-pages but not others
Guests inherit permissions from a parent page only if the sub-pages do not have their own explicit permissions. If a sub-page was previously shared with a different guest or a workspace member, its permission list is separate. The original guest will not see that sub-page unless explicitly added to it.
Permission Inheritance Behavior: Parent Page vs Sub-Page vs Database
| Item | Parent Page (Shared With Guest) | Sub-Page (No Explicit Permissions) | Sub-Page (Explicit Permissions Set) |
|---|---|---|---|
| Permission source | Uses its own Share menu | Inherits from parent page | Uses its own Share menu |
| Guest sees sub-page? | N/A | Yes | Only if guest is in sub-page’s list |
| Sub-page inside database | N/A | Inherits from database, not from the page that contains the database | Uses its own Share menu |
| Linked database view | N/A | Inherits from source database | N/A (linked database has no separate permissions) |
Notion’s permission inheritance is predictable once you know the rule: permissions cascade down unless a sub-page has its own explicit settings. Use the Share menu on each sub-page to check whether it says “inherits permissions” or lists people. To force a sub-page to stop inheriting, add at least one person to it. To force a sub-page to start inheriting, remove all people from its Share menu. For database sub-pages, remember that the database is the parent, not the page that contains the database. A useful advanced tip: you can create a group in Notion and share that group with the parent page. All sub-pages that inherit permissions will then apply group-level access, making permission management much easier across large workspaces.