Granular Database Permissions in Notion: Ultimate Guide

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.

March 2026 Update: Notion has released a new “Can Create Pages” toggle that lets users with No Access, Can View, or Can Comment permissions create entries in a database — without needing full edit rights. This update significantly changes how client portals, locked databases, and internal document workflows are set up. We cover the full details in our dedicated article: Notion’s New Can Create Pages Permission. The relevant sections of this guide have been updated below to reflect the new capabilities.

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

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

---

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

1. Open the source database as a full page. Linked views or inline tables won’t display the granular permissions interface.
2. Click the Share button in the top right. You’ll see the new Page‑level access section.
3. 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.
4. 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.
• Users without database access cannot create linked views via slash command. If a user has No access on the database, typing /linked view will not show the database in search results. The workaround is to provide a pre‑built linked view that users can duplicate, or embed linked views directly into your team’s standard dashboards and pages. This applies to both external guests and internal team members who rely on page‑level access rules.
• Users without database access can now create entries using the “Can Create Pages” toggle. As of March 2026, you no longer need forms as the only way to let users add rows to a locked database. In the Share dialog, set a user to No Access, Can View, or Can Comment, then switch on the Can Create Pages toggle. Pair this with a page‑level access rule (e.g., Created by → Can Edit) so the creator can edit their own entry. Notion Forms remain a valid alternative if you want a more structured submission experience. See our full walkthrough of the Can Create Pages permission for setup steps.
• 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)

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.” Enable Can Create Pages if users need to add their own tasks.	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. Enable Can Create Pages to let guests submit new entries directly. See Can Create Pages guide.	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. Use a database button to lock down individual entries with one click.	HR records or any documents that only certain groups should see.
Add new entries to a locked database	No access + Can Create Pages (users can create but not browse)	Person property: Created by Permission: Can edit or Can edit and share	Enable the Can Create Pages toggle in the Share dialog. Notion prompts you to add the page‑level rule automatically. Share a linked view. Full walkthrough → Alternative: Use a Notion Form for structured submissions.	External partners, clients, or internal teams who need to submit entries to a controlled database.

✅ Edit your own tasks

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

Setup:

1. Set general database access for the team group to Can view (or Can comment if you want them to leave comments on all tasks).
2. Create a page‑level rule: select the Owner (or Assignee) property and set the permission level to Can edit.
3. 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:

1. Set general database access to Can edit content so users can update their documents but not share them (or mess up the database structure).
2. 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:

1. Remove all general access from the database (No access).
2. Add a rule on the Owner or Assignee property and set the permission to Can edit (for freelancers) or Can view (for clients).
3. 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.

Letting clients create new entries: With the new Can Create Pages toggle (March 2026), you can also let external guests add entries directly. Set their database permission to No Access + Can Create Pages, add a page‑level rule on the Created by property, and share a linked view. The guest can now submit new tasks or requests without you needing to set up a form. For step‑by‑step setup, see Notion’s New Can Create Pages Permission.

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:

1. Set general database access to No access.
2. 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.
3. 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.

Alternative: Using Can Create Pages + Database Buttons

With the March 2026 update, you can simplify this pattern further:

1. Lock down the database and give your company‑wide group No Access + Can Create Pages. This prevents browsing the raw database but lets everyone create new entries through a linked view.
2. Set up a database automation: When a page is added, set the Access person property to your “Team All” group. Every new entry becomes visible to everyone automatically.
3. Create a database button to lock down sensitive entries. The button should show a confirmation prompt (“Are you sure you want to restrict this document?”), then replace the Access property value with the restricted group (e.g., “HR” or “Admin”). When clicked, the entry disappears from everyone else’s view.

This creates a self‑service system: documents are open by default, and locking something down is a single click. For full implementation details, see Notion’s New Can Create Pages Permission.

✅ Allow users to add new entries to a locked database

As of March 2026, Notion’s “Can Create Pages” toggle is the simplest way to let users add entries to a database they don’t have edit access to. No forms, no external tools.

Primary method — Can Create Pages:

1. Open your database and click Share in the top right.
2. Add the user (guest or team member) and set their permission level to No Access (or Can View / Can Comment depending on whether they should see other entries).
3. A new toggle appears: Can Create Pages — switch it on.
4. Notion will prompt you to add a page‑level access rule so the creator can edit their own entries. Accept this and choose either Can Edit or Can Edit and Share.
5. Share a linked view of the database with the user.

The user now sees the linked view (empty if they have No Access, or showing their permitted entries if they have Can View/Can Comment) and can click New to add entries. Once created, the page‑level rule kicks in automatically — they can see and edit what they created, but nothing else.

Pro Tip: The “Can Create Pages” toggle is available on three permission levels: No Access, Can View, and Can Comment. It disappears at Can Edit Content and above because those levels already include creation rights by default.

Alternative method — Notion Forms:

If you want a more structured submission experience (e.g., pre‑filled fields, required properties, or a guided input flow), Notion Forms are still a solid option:

1. Create a form linked to the database.
2. 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).
3. 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.

For a detailed walkthrough of the Can Create Pages feature, including setup screenshots and edge cases, see our dedicated guide: Notion’s New Can Create Pages Permission.

---

Limitations and gotchas

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 content.
• Highest permission wins. If a user has higher access through another share or group, they’ll keep that higher access despite your page‑level rules.
• 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.
• Linked views can’t be created via slash command without database access. If a user has No Access on the database, it won’t appear in search when they type /linked view. The workaround is to provide pre‑built linked views that users can duplicate, or embed them in your team’s standard dashboards.
• Minor delay when opening freshly created entries. When a user creates a new entry via the “Can Create Pages” permission, there can be a brief delay before the entry is fully openable. Refreshing the page resolves this. This is expected to be patched soon.
• No native “lock this page” button. While you can build a lock‑down workflow using database buttons and automations (see the Secure HR Documents use case above), Notion doesn’t yet have a built‑in single‑click “make this private” action.
• 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.

How does the new “Can Create Pages” toggle work?
As of March 2026, users with No Access, Can View, or Can Comment on a database can be granted the ability to create new entries via a toggle in the Share dialog. When enabled, Notion prompts you to add a page‑level access rule so the creator can edit their own pages. The toggle disappears at Can Edit Content and above, since those levels already include creation rights. See our full guide to the Can Create Pages permission for details.

---

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.