Granular Database Permissions in Notion: Ultimate Guide

Written by: Matthias Frank

Last edited: September 19, 2025

Notion 3.0 finally delivers one of the most‑requested enterprise features: granular database permissions, also known as page‑level access.

Until now, Notion only allowed you to share entire databases or manually adjust the permissions of individual pages.

That old constraint forced teams to build awkward workarounds with duplicate databases and third-party integrations.

With granular permissions, you can control who sees and edits each row in a database, unlock secure client portals and HR records, and still maintain a single, scalable database structure.

This guide explains how granular database permissions in Notion work, why they matter, and how to implement common use cases like edit‑your‑own tasks, client portals, and protected HR documents.

It also clarifies limitations and best practices so you can avoid surprises when rolling out this feature across your workspace.

YouTube video

What are granular database permissions?

Granular database permissions (which Notion calls page‑level access) let you set different permission levels for each entry in a database based on the values of a person or created by property.

When you add a rule, Notion applies the chosen permission level – Can view, Can comment or Can edit – to any row where that property matches the current user.

This means you can give each person full editing rights over their own tasks while limiting them to read‑only access for everyone else.

Here are the most important things to keep in mind:

Only available on Business and Enterprise plans. If you’re on a personal or free plan, you’ll still need workarounds.
Works on the source database. You must open the database as a full page to see the Page‑level access section in the Share dialog.
Rules reference person properties or the built‑in “created by” property. You select the property and then pick the permission level you want to assign.
Rules apply across all views and linked views. Once a rule is set, the corresponding rows respect that permission in every view of the database.
Rules can only increase permissions, not reduce them. That means you need to set your source database to the lowest required permissions and use page rules to increase them for specific user groups.

Notion’s six base permission levels—Full access, Can edit, Can edit content, Can comment, Can view, and No access—still apply.

Granular database permissions in Notion don’t introduce new levels; they simply allow you to assign one of the existing levels programmatically.

Remember that Can edit content is only available on full‑page databases and does not appear in page‑level rules.

Why does it matter?

Before this release, the only way to restrict access was to share or hide entire databases.

If you wanted to show a filtered view to a client or colleague, you had to duplicate the database or use complex API automations to sync data into a “public” copy.

That made it hard to maintain a single source of truth.

Granular permissions now let you keep all your data in one place while limiting access to the right people, simplifying workspace architecture and improving security.

Setting up granular permissions in Notion

Open the source database as a full page. Linked views or inline tables won’t display the granular permissions interface.
Click the Share button in the top right. You’ll see the new Page‑level access section.
Add a rule:
- Select Add a new rule.
- Choose a person property (e.g., Assignee, Owner) or the built‑in Created by property.
- Pick a permission level (Can edit, Can comment or Can view).
- Click Create rule.
Repeat for other person properties if needed. Each property can have its own rule.

That’s it. Notion will automatically apply these permissions to rows where the selected property matches the current user.

Understanding how it works

People must have some level of access to the database to open linked views. If a user only has row access but no database access, they will see an error when visiting the source database. Linked views of the database will appear empty until a user can access at least one entry via page rules
Linked views enable editing without exposing the entire database. In the linked view, users can edit the rows where they have Can edit rights, even if they can’t edit the source table.
Forms are required to create new rows if the database is locked down. Users without database access cannot click the “New” button or drag tasks into the table. To let them add tasks, create a Notion form that sets the Owner or Assignee property to the current user by default. Please note that this currently only works for members of the workspace, not for guests.
Highest permission wins. Notion always grants the broadest permission a user has. If they have Can edit through a page‑level rule but Full access via a group, they will still have Full access. Page‑level rules cannot reduce someone’s permissions.

Best practices for Granular Database Permissions in Notion

1. Start with the most restrictive general access

Set the default database permissions to the lowest level you want across your team (often Can view or even No access). Then use page‑level rules to increase permissions. Because permissions only go up, not down, starting from a permissive level makes it impossible to later restrict certain users.

2. Use groups for baseline access

Assign general database access via user groups rather than individual people. This makes it easy to manage team‑wide permissions and ensures new hires automatically get the correct access. You can mention groups in person properties to give all members of that group the same row‑level access. Note that group mentions currently don’t work with the “Me” filter.

3. Keep your databases set to `Can edit content`

Admins should have Full access, but everyone else should generally have Can edit content on the database to prevent accidental changes to fields, views and filters. Your page‑level rules will then grant or revoke editing rights on specific rows.

4. Be mindful of inherited permissions

Subpages inherit permissions from their parent page unless you override them. If you move a database into a private section of your sidebar, only people with explicit access will see it.

Common use cases for Granular Database Permissions in Notion (and how to implement them)

Granular Database Permissions Use‑Case Overview

Use case	General database permission	Page‑level rule	Additional setup	Best for
Edit your own tasks	Can view or Can comment (restrict general access)	Person property: Owner/Assignee Permission: Can edit	Share a linked view filtered to “Owner = current user.” Use a form if users need to create tasks in a locked database.	Team task databases where everyone can see all tasks but only edit their own.
Creators can share their pages	Can edit content (users can modify content but can’t share pages)	Person property: Created by Permission: Full access	None; creators get full sharing rights on the pages they make.	Wikis or document hubs where authors need to share their pages with others.
Client portal/Freelancer dashboard	No access (lock down the database for everyone else)	Person property: Owner/Assignee Permission: Can edit for freelancers or Can view for clients	Provide a linked view filtered to show only the user’s own items.	External partners who should see only their tasks or documents.
Secure HR & sensitive docs	No access (start fully restricted)	Use automations instead of rules: assign a “Team All” group by default; remove it when the page is tagged “HR” and add the appropriate private group.	Requires automations to add and remove groups based on tags or status.	HR records or any documents that only certain groups should see.
Add new entries via form	No access (users can’t use the standard New button)	Person property: Owner/Assignee Permission: Can edit (set via rule)	Create a Notion form that sets the Owner/Assignee to the current user when submitted; share or embed the form.	Portals or databases where the main table is locked but users need to submit items.

✅ Edit your own tasks

Goal: Team members can view everyone’s tasks but only edit their own.

Setup:

Set general database access for the team group to Can view (or Can comment if you want them to leave comments on all tasks).
Create a page‑level rule: select the Owner (or Assignee) property and set the permission level to Can edit.
Share a linked view of the database with your team. When they open a row they own, they’ll be able to edit it; other rows will be read‑only.

This pattern is ideal for task management, content calendars or any list where individuals own specific items.

✅ Let creators share their pages

Goal: A document owner should be able to share their document with others without giving the entire team full database access.

Setup:

Set general database access to Can edit content so users can update their documents but not share them (or mess up the database structure).
Add a rule on the Created by property and set the permission level to Full access.

Now, the person who created a page can invite guests or teammates to collaborate on that particular page, while everyone else remains restricted to editing content only.

✅ Client portals and freelancer dashboards

Goal: Share only the tasks or documents relevant to a specific external client or freelancer.

Setup:

Remove all general access from the database (No access).
Add a rule on the Owner or Assignee property and set the permission to Can edit (for freelancers) or Can view (for clients).
Create a linked view filtered by Owner = Current user. Share this view with the external person.

The client or freelancer will only see their assigned tasks. They cannot open the full database and will never see tasks belonging to other clients.

Alternatively, you can also use a tool like Softr to build custom client portals on top of your Notion database system.

✅ Secure HR or sensitive documents

Goal: Keep HR records private while making all other documents visible to everyone.

Because granular permissions cannot reduce a user’s permissions, you need to reverse the usual pattern:

Set general database access to No access.
Create an automation that automatically assigns a “Team All” group to every new page. This ensures that all pages are visible to everyone by default.
Create a secondary automation: when a page is tagged “HR” (or any other protected tag), remove the “Team All” group and assign the appropriate private group instead.

This approach keeps sensitive entries hidden without requiring manual permission changes.

✅ Allow users to add new entries to a locked database

When the database has No access, users can’t click the “New” button. To let them add items:

Create a form linked to the database.
Pre‑fill the Owner or Assignee property with the person filling out the form (many teams use an automation that copies the Created by value into the Owner property).
Share the form or embed it on a page. Users can create entries through the form, and since they become the owner, the page‑level rule grants them editing rights.

This pattern is handy for client portals and HR requests.

Limitations and gotchas

Granular permissions don’t apply to views or columns. You can’t hide specific properties or views; everyone with access to a row sees its entire content. If you need column‑level security, you still need to maintain separate databases or use API‑driven workarounds.
No “Can edit content” option in page‑level rules. Page‑level rules can grant Can edit, Can comment or Can view, but not Can edit contentnotion.com.
Highest permission wins. If a user has higher access through another share or group, they’ll keep that higher access despite your page‑level rulesnotion.com.
Groups in person properties don’t filter in the “Me” view. Mentioning a group in a person property grants access, but filters like “Assignee is Me” don’t yet recognise group membership. You may need separate filters or automations for group members.
Small UI quirks. Users may need to open a row once before they can edit it in a linked view, and there may be delays before permissions update. These are likely to improve as the feature matures.

Frequently asked questions (FAQ)

Here’s everything you should keep in mind about granular database permissions in Notion.

What plans include page‑level access?
Granular database permissions are available on the Business and Enterprise plans.

Do I need a person property for this to work?
Yes. Page‑level access rules rely on a person property or the built‑in Created by property.

Can I set different permission levels for different person properties?
Yes. Each person property can have its own rule. When multiple rules apply to a row (e.g., both the Assignee and Reviewer properties reference the same person), the highest permission wins.

Can I restrict someone’s access through a page‑level rule?
No. Page‑level rules cannot reduce permissions; they can only grant additional rights. To reduce someone’s access, adjust the general database permissions or remove them from groups.

How do linked views work with granular permissions?
If a user lacks database access but has row‑level access, they will see an error when opening the source database. However, they can edit or view their rows in a linked view that you share with them. The linked view will be empty until at least one entry becomes visible to the user.

Can guests use page‑level access?
Yes. Assign them to the relevant person property and share a linked view. They’ll only see and edit the entries assigned to them.

Conclusion

Granular database permissions in Notion are an important building block to create secure, scalable operations for your team.

Instead of duplicating databases or building complex automations, you can now assign row‑level access based on person properties, keeping a single source of truth while protecting sensitive information.

Use the patterns described above to implement common scenarios like task management, client portals and HR records.

As the feature evolves, we expect further refinements such as column‑level permissions and better integration with group filters.

Until then, following these best practices will ensure a smoother rollout and make your team’s Notion workspace both secure and scalable.

And if you need help with implementing granular database permissions for Notion or any other advanced systems for teams, let us know. We have a team of certified Notion Consultants ready to help you transform your operations.