How to Bulk-Update Permissions Across Notion Pages

Managing page permissions one at a time in Notion becomes impractical when you need to share dozens of pages with a new team member or revoke access from a former collaborator. Notion does not offer a native bulk-permission editor, but you can achieve the same result using databases, grouping, and workspace-level settings. This article explains how to update permissions for multiple pages at once using linked databases and workspace member management. You will learn three distinct methods that work for personal pages, team spaces, and shared databases.

Why Notion Lacks a Native Bulk-Permission Editor

Notion treats each page as an independent object with its own permission settings. The Share button on a page controls who can view, edit, or comment on that specific page. There is no check-box list of pages that you can select and apply a permission change to all at once. This design prevents accidental mass exposure of private content, but it forces administrators to find workarounds when they need to update permissions for many pages at the same time.

The most reliable workaround relies on inheritance. When you share a parent page with a person or group, all sub-pages inside that parent automatically receive the same permission level unless you override them individually. Similarly, when you share a database, every page inside that database inherits the database-level permissions. Understanding these two inheritance rules is the foundation for every bulk-update method in this article.

Method 1: Move Pages Into a Shared Database

This method works when you have existing standalone pages that you want to give the same permissions to a set of users. By converting those pages into database entries, you can share the database once and all entries inherit the permissions.

1. Create a new database
   On the page where you want the database to live, type /database and select Table or Board. Name the database clearly, for example “Shared Project Pages.”
2. Move each standalone page into the database
   Open the standalone page, click the three-dot menu in the top-right corner, select Move to, then choose the database you just created. The page becomes a row in the database. Repeat for every page you want to include.
3. Open the database permissions
   Click the Share button in the top-right corner of the database page. By default, the database inherits permissions from its parent page, but you can override them here.
4. Add people or groups
   In the Share menu, type the name of a person or a workspace group in the Add people or groups field. Choose the permission level: Can view, Can edit, or Can comment.
5. Confirm inheritance
   Click Copy link and send it to the users. They will see all database rows, including the pages you moved. Any new page you add to the database will also inherit these permissions automatically.

Limitations of This Method

Moving a page into a database changes its URL and its location in the sidebar. Users who had bookmarks to the old page URL will need the new link. Also, if the original page had its own custom permissions that were more restrictive than the database permissions, those restrictions are lost after the move.

Method 2: Use a Parent Page With Inheritance

If you do not want to convert pages into database rows, you can nest all target pages under a single parent page. The parent page acts as a permission hub.

1. Create a parent page
   Click + New page in the sidebar and give it a name such as “Team Access Hub.” Do not add any content yet.
2. Move all target pages into the parent
   For each page you want to share, open the page, click the three-dot menu, select Move to, then choose the parent page you just created. The pages become sub-pages of the parent.
3. Share the parent page
   Click Share on the parent page. Add the people or groups you want to grant access to. Choose the permission level.
4. Verify sub-page inheritance
   Open any sub-page and click Share. You should see a note that says “Inherited from parent page.” The sub-page cannot be individually shared unless you explicitly override it.
5. Override individual sub-pages if needed
   If a specific sub-page should have different permissions, open that sub-page, click Share, and add a person or group. That override takes precedence over the parent inheritance.

Limitations of This Method

Nesting pages changes the sidebar hierarchy. If your workspace relies on a flat sidebar structure, this method may disrupt navigation. Also, users who had direct access to a sub-page before the move will lose that access unless you re-add them to the parent page.

Method 3: Use Workspace Groups

Workspace groups let you assign permissions to a group of users at once. When you add or remove a member from the group, the permission change applies to every page that has that group added.

1. Create a workspace group
   Go to Settings & Members in the left sidebar, then click Groups. Click Create a group, give it a name such as “External Editors,” and add the members.
2. Add the group to a page
   Open any page that should be accessible to the group. Click Share, type the group name in the Add people or groups field, and select the permission level.
3. Repeat for every page
   You still need to add the group to each page individually. However, once the group is added to a page, you never need to modify that page again when members change.
4. Update group membership
   When a new person needs access, go to Settings & Members > Groups, open the group, and add the person. That person immediately gains access to every page that includes the group. To revoke access, remove the person from the group.

Limitations of This Method

Workspace groups are available only on Notion Plus, Business, and Enterprise plans. Free plan workspaces cannot create groups. Also, you must add the group to each page manually the first time — there is no way to apply a group to all existing pages in one action.

If Notion Permissions Still Do Not Update as Expected

Sub-page shows “Inherited from parent” but user cannot access it

The parent page’s Share menu may have been set to a specific person but the parent page itself is located inside a workspace that has different permissions. Check the workspace-level sharing settings: go to Settings & Members > Workspace and verify that the workspace access is not set to Private for that user. If the workspace is private, the user must be a workspace member first, then the parent page sharing will work.

Database rows do not inherit database permissions

If a database row (page) was created before you changed the database permissions, it may have its own individual permission override. Open that row, click Share, and remove any explicit people or groups listed. The row will then fall back to the database-level permissions.

Group permissions do not apply to sub-pages

Groups, like individual users, follow the same inheritance rules. If you add a group to a parent page, sub-pages inherit that group permission. If you add a group directly to a sub-page, that sub-page does not automatically grant access to sibling pages. Always apply the group at the highest parent page that contains all pages you want to share.

Permission Inheritance vs Manual Sharing: Key Differences

Item	Inheritance (Parent Page)	Manual Sharing (Each Page)
Setup effort	Share one parent page	Share each page individually
Ongoing maintenance	Add pages to parent; permissions auto-apply	Must re-share each new page
Risk of accidental exposure	Lower, because permissions are centralized	Higher, because each page can be forgotten
Sidebar impact	Pages become nested	Pages stay at their original location

Inheritance saves time when you regularly add new pages that need the same audience. Manual sharing gives you full control over each page’s audience but requires more work as your page count grows.

You can now update permissions for multiple Notion pages without editing each page’s Share menu. Start by choosing the method that fits your workspace structure: use a shared database for pages that already exist as database rows, a parent page for a flat hierarchy, or workspace groups for recurring member changes. To avoid permission drift, audit your parent pages and groups every quarter by reviewing the Share menu on the top-level page.