Notion Granular Database Permissions: The Complete Guide

Notion finally has granular database permissions, making it possible to grant access to a slice of a database – rather than forcing you to grant a user access to the entire database.

This is a feature that I’ve been asking Notion to build for a long time. The same is true for many, many people running teams and working with clients. This release makes me one very happy Notion nerd.

Here are a just a few things you can build with this feature:

• Task managers where each team member can only access Tasks where they are the Assignee
• Team note-taking systems that are read-only by default, with each note only editable by its associated project leader
• Client dashboards powered by a central Requests database, where each client can only access their own requests

Here’s a quick look. See the yellow Key (🔑) icon in the Assignee property? This indicates that users set in that property will gain access to the page, even if they don’t have the same level of permission for the whole database.

I’ve long referred to this set of features as “granular database permissions”. If you’ve worked with true relational databases before, like Postgres or MySQL, you might know it as row-level security.

Notion is calling it page-level access. Whatever term you choose to use, the upshot is that you can create rules that set permissions for users based on a database page’s property values.

In this guide, I’ll turn you into an expert on this feature and show you exactly how to implement it in your workspace. I’ll also cover some of the current limitations of this feature, and provide a few workaround options.

Page-Level Access at a Glance

Here’s your 30-second summary on page-level access rules.

• Page-level access rules let you grant access to pages in a database by adding users to database properties.
• Create a page-level access rule by going to the source database (full page), clicking Share, then creating a rule in the new Page-level access section.
• Supported property types include Person and Created by.
• Your workspace needs to be on the Business or Enterprise plan to use this feature.
• You need Full Access to a database in order to create or edit page-level access rules.
• Page-level access rules are set at the data source level. If your database has multiple data sources, you’ll see a dropdown allowing you to pick the data source on which you want to create a rule.

Here are a significant limitations around this feature, as of this writing:

• Other property types – notably Rollups – can’t be used to create page-level access rules. This makes it hard (but not impossible) to make permissions “trickle down” – e.g. people with access to a Project getting access to all its Tasks.
• If a user doesn’t have Can Edit access to the entire database, they can’t easily create new pages. There’s no separate Can Create permission rule yet.
• There are no property-level permissions rules yet, so you can’t restrict access to specific properties.

Finally, here are a few workarounds for these limitations:

• Notion automations can create “trickle-down” permissions (e.g. project access grants access to all tasks in project)
• Workspace members can create new pages through a Notion Form.
• You can set up a Tally form and automation to allow guests to create new pages (e.g. clients in an agency workspace)
• You can use a tool like Softr to create portals that expose only certain properties

Keep reading to get more detail on each point in this summary.

Who Can Use Page-Level Access

Page-level access rules can be created if your workspace is on Notion’s Business or Enterprise plans. This means you’ll be paying at least $20/mo, per workspace member, to use this feature.

Many teams have already upgraded to Notion’s Business plan in order to access the included Notion AI features, but if your team is on the Plus plan, you won’t be able to create page-level access rules.

Luckily this feature applies to workspace guests – not just members! This is great news for all of you who are running agencies or managing client relationships in Notion. Instead of paying for each client to be a member, you can add them to your workspace as guests for free.

You’ll also need to make sure that you have Full Access to any database where you want to create page-level access rules. Users with lower-level access – even Can Edit – won’t be able to create these rules.

Need a refresher on permissions? Read my comprehensive guide to Notion sharing and permissions here.

How to Create Page-Level Access Rules

You can create a page-level access by:

1. Going directly to a database’s actual, full-screen page (not a linked view)
2. Clicking the Share button
3. Creating a rule in the new page-level access section

As an example, let’s improve a Tasks database by allowing Assignees to view and edit their tasks. In the Tasks database below, you can see the database-wide permissions. I have Full Access, as do the Owners of the Teamspace. No one else has any level of access to the database itself.

However, I’ve added a page-level access rule as well. Anyone in the Assignee property gets Can Edit permission on that page.

Here’s how this rule ends up working in practice.

If we look at the task manager, we can see that our team member Edward Elric has two assigned tasks (one of which doesn’t sound very fun…)

See the little yellow 🔑 icon on the Assignee property? This indicated that the property is being used in a page-level access rule.

If I log into Notion as Edward (he won’t mind, being a fictional character and all), here’s what his view of the Tasks database looks like. Notice that there aren’t any filters applied to this view of the database! These two tasks are the only ones he can access.

If we open a task as a full-screen page (still logged in as Edward), you’ll also notice that we don’t see the same trail of breadcrumbs we’d normally see.

Again, this is due to the fact that Edward has No Access to the database that contains the page. He can only access pages where his user account has been added as a value in the Assignee property.

Benefits of Page-Level Access

If you’re newer to Notion, you might be asking an important question:

“How is it any faster to add a user to a Person property than it is to just share a page with them the normal way?”

This is a good question! You’ve always been able to share Notion pages directly, even if a user doesn’t have access to the database that contains them.

However, page-level access rule give you tools to grant these permissions much faster, and in many cases automatically. You can use page-level access rules to quickly grant permissions via:

• Database filters and groupings
• Database templates
• Database automations
• Notion API automations

First, you can use database filters and groupings to automatically add specific users to a Person-type property. When a page is created in a view that contains filters, Notion will try to force the page’s properties to take on values that fit those filters. In this way, filters act as forcing functions that automatically set property values.

The same is true of groups in a database view; when you click the New Page button within a group, Notion tries to make sure the created page fits that group.

Note: I use the word “try” because Notion can’t make a page fit a filter that targets a read-only property. For example, a Created By property is read-only; it displays the person who created the page, and there’s no way to change that value.

You can see this in action below; when I create a new task in the Edward Elric group, he automatically becomes the Assignee. Due to the page-level access rule I have set up, this means he automatically gets access to the task as well!

You can also automatically set the values of Person-type properties through database templates.

Learn how to create and edit database templates in my Notion databases guide.

For example, this Grunt Work Task template in my Tasks database automatically sets Edward as the Assignee. Poor sod.

The moment this template is applied to a page, he’ll gain access to it through our page-level access rule. And don’t forget that you can set database templates as defaults for new pages – both in specific views, or for every view in the database!

Another way to automatically add users to Person properties, and thus grant them access to pages, is through database automations.

This can be really powerful. For example, this automation in a Projects database will automatically edit the permissions of every task related to a project when the project’s Project Members property is edited.

If you want to see exactly how to set this automation up, check out the section below on granting permissions through a Relation.

If you want to learn what you can do with database automations, check out this video:

You’re not limited to internal database automations, either. You can also use the Notion API to modify Person properties, adding or removing user IDs as needed.

This means you can use tools like Pipedream, Zapier, Make.com, n8n, Relay, etc. to build automations that grant or remove page access in a database.

Want to build an automation that assigns tickets in a Customer Support database using round-robin scheduling? You can do that – and a whole lot more.

Fun fact: This is the first instance where the Notion API has any form of control over page access for specific users. For certain users, this is a certified Big Deal™.

Multiple Data Sources and Page-Level Access

If you’re working in a database that contains more than one data source, you’ll notice a small dropdown menu in the page-level access section of the Share menu. This lets you select the data source on which to create a page-level access rule.

For example, here’s what our page-level access section looks like after I moved a Projects data source into our original Tasks database. As you can see, the database now contains two data sources – Tasks and Projects – and any rule I create only applies to the currently-selected data source.

That’s right – page-level access rule are set at the data source level, not the database level. They apply only to a single data source.

Feeling shaky on databases and data sources? You’re not alone – this distinction confuses a lot of folks! Check out my full guide to multi-source Notion databases to clear everything up.

This makes sense, since these rules target a specific property. For example, the Projects data source might have a Project Lead property, while the Tasks data source within the same database might not.

Even if every data source in a database has a property with the same name and type (e.g. Assignee), they’re all still unique, separate properties that are contained by their specific data sources.

This does mean that the whole permissions picture is bit more complex, though. So here’s the new breakdown.

Database-level permissions are set at the database level, and apply to all data sources. For example, you can’t set a “Can Edit” rule for a user on just one data source. That rule is set on the database.

Page-level access rules are set at the data source level, so they’ll only apply to that data source alone. Use the dropdown menu to create rules for other data sources.

Supported Property Types

Page-level access rules work like this:

“If a user’s profile is set on [Property A] on this page, give that user [some level of access].”

The example I’ve shown above grants a user the Can Edit permission level if they are in the Assignee property on a page.

Currently, there are two supported property types that can be used to create page-level access rules:

1. Person
2. Created By

Notably, the highest level of access you can grant using each of these two property types is different!

Created By properties can grant any level of access, including Full Access.

Person properties can grant Can Edit access or lower. They cannot grant Full Access, and for good reason. If they could, a user who currently has Can Edit or Can Edit Content could simply add themselves to a Person property and upgrade their own access.

While these two property types handle most simple use cases, I’m hoping Notion will expand this list soon to include Rollup properties. Without support for Rollups (or Formulas, but I’m not holding my breath on that one), it’s tougher to create rules like:

“If User is in the Project Members property on [Project], grant Can Edit access to all Tasks related to [Project]”.

I elaborate on this more in the Limitations section, and provide a workaround as well.

Members, Guests, and Groups

Good news: Page-level access rules work for both members and guests!

Don’t know about members and guests? Check out the Members vs. Guests section in my Notion permissions guide.

Additionally, if you add a Group to a Person property, everyone in the Group will get access to the page as defined in your page-level access rule.

Not sure what a Group is? Check out the section on Groups in my Notion permissions guide.

So why is this an entire section? Well, first, it’s a common question and creating a whole section ensures the answer’s in the guide’s Table of Contents.

Secondly, as expected, there are quirks.

Let’s talk about members and guests first. When it comes to granting access to existing pages, there’s no difference between the two. When you click a Person property, you’ll see all the members and guests in your workspace. Whoever is set as a value in the Person property will be granted the access defined in the rule.

However, things differ around creating new pages. As I detail in the section below on creating new pages, anyone who lacks Can Edit Content (or higher) access at the database level can’t create new pages in the database normally. I detail the reasons for this in that section.

Luckily, there are workarounds for both members and guests, which I detail in that section.

Second, there’s one quirk that has to do with Groups. While Groups can be selected in any Person property, and work as expected with page-level access rules, they aren’t included in database views where you’ve applied a Me filter.

This is a hidden “gotcha” that can affect specialized views of databases. For example, you might have a My Tasks view of a Tasks database, filtered to only show pages where the Assignee value is Me.

This is a fantastic way to create a single page that everyone on your team can use – but know that this view won’t show tasks where a user is part of the Assignee property via a Group! Their user account needs to be set in the Assignee property directly.

It’s more of a quirk that affects database filters than one specific to page-level access rules, but it’s worth mentioning here.

Limitations

Page-level access rules have four main limitations:

1. Page-level access rules won’t allow users to create new pages
2. Page-level access rules won’t allow users to delete pages
3. Lack of Rollup support
4. No ability to lock down specfic properties

Limitation 1: Creating New Pages

The first limitation is perhaps the most frustrating (although I’ve figured out workarounds I’ve shared below). Using page-level access rules, there’s no way to allow users to create new pages in a database – at least not directly.

To do so, they would still need to have Can Edit Content (or higher) access to the database itself. Page-level access rules only target existing pages, since page needs to exist in order to for a user to be set as a value in one of its properties!

Fortunately, you can get around this limitation for now by creating forms that allow your users to create new pages indirectly.

Limitation 2: Deleting Pages

Page-level access rules also won’t allow a user to delete a page. This is true even if the user has Full Access to the page via a rule targeting a Created By property.

The reason for this is exactly the same reason that prevents users from creating new pages: they need Can Edit Content (or higher) access to the actual database.

The logic for creation and deletion is the same: Both actions are technically an edit to the parent page or data source that contains page being created or deleted. Therefore, the user needs the ability to edit that parent.

This issue never really popped up with respect to page-creation before page-level access rules were released, but it’s actually a common point of confusion when it comes to page-deletion. Folks often think that having Full Access to a page is enough to delete it, not realizing that they also need to be able to edit the page’s parent.

I’ve gone deep into detail about who can delete a page in my Notion permissions guide, so read that section if you want a better understanding.

To overcome the page-deletion limitation, you would need to add a “Trash this page” Button property to your database, then have it fire a webhook event to an external automation with Can Edit access to the database.

Limitation 3: No Rollups

The third limitation is that page-level access rules don’t support Rollup properties. This doesn’t seem like all that big a deal… until you start trying to build truly useful systems that teams actually need. A good example is a Tasks and Projects tracker, where a user invited to a Project automatically can access all the tasks within it.

If a page-level access rule could target a Rollup property, this would be easy to set up. Just create a Rollup on your Tasks database that pulls in a “Project Members” Person property from the Projects database, then target it with a page-level access rule. Boom, you’re done. The moment you apply a Project relation to a new Task, the task will become accessible to the project members.

I’ve shared this as feedback to the Notion team, so I’m very much hoping we’ll see Rollup property support in the future. I don’t expect we’ll see Formula support, which would be useful for similar purposes, since formulas can get very computationally expensive. Good recipe for making Notion unbearably slow.

But my sense is that supporting Rollups – specifically those that are targeting Person properties – won’t carry the same cost.

Fortunately, while Rollup support is missing, you can approximate its functionality by setting up a few automations!

Limitation 4: No Property Permissions

Finally, the page-level access rule feature doesn’t provide any way to lock down specific database properties.

This would be a very useful feature. Imagine you shared pages from a YouTube Projects database with a contracted video editor – you might not want them to see a Sponsor Rate property!

Currently, the only way to accomplish this would be to use Notion as a back-end data source and build a portal on top of it using a different app. I cover a couple options for doing that in my Alternatives section below.

Creating New Pages

Right now, one of the biggest limitations with page-level access rules is that they don’t provide a way for users to create new pages in a database.

If a user doesn’t have Can Edit Content (or higher) access to the database itself, they won’t be able to create new pages directly.

Notion is working to fix this limitation, but there’s currently no ETA on a fix. Luckily, I’ve got a couple of workarounds that you can use in the mean time!

• For workspace members, you can set up a Notion Form they can use to create new pages
• Workspace guests can’t use a Notion Form, but you can set up a Tally form with an external automation (e.g. on Zapier or Pipedream) that will allow them to create new pages as well

Before we dive into the details of these workarounds, let me quickly address one that doesn’t work.

You might have the idea to create a Button block that contains an “Add Page” action. Unfortunately, this won’t work; if a Button contains an action that would add a page to a database, a user needs to have Can Edit Content (or higher) access to that database in order to be able to click the button.

Best For Members: Notion Forms

While members can’t create new pages directly if they don’t have Can Edit Content (or higher) on the database, they can create new pages through a Notion Form.

You can easily add a new Form to an existing database by:

1. Navigating directly to the database itself (not a linked view – Forms must be created directly on their data source)
2. Creating a new view
3. Choosing the Form type

If you need a full rundown on Forms, here’s the video for you:

When a member fills out a form that has the default Share setting of “Anying in [this workspace] with the link”, their user account will become the value of the Created By property (if your database has one).

You can then create a page-level access rule targeting the Created By property in order to grant the user access the page created through their Form submission.

Alternatively, you can actually grant access to the new page directly through the Form:

1. Click Share Form
2. Click Access to submission
3. Choose a level of access

There’s a subtle, but pretty important difference between these two methods.

If you go the route of the page-level access rule, you won’t be able to remove or downgrade a user’s access to a specific page they’ve created. This is due to the fact that the page-level access rule will always grant them its intended level of access to the page – even if you were to downgrade their actual user account’s permissions on that page.

In Notion, when multiple permissions rules apply to a user, the highest (i.e. most permissive) rule wins. More restrictive rules can’t “override” more permissive ones. This means you’d have to delete or downgrade the page-level access rule itself – which would affect all pages, and potentially multiple users!

This is only a concern when a page-level access rule targets a Created By property, since you can’t change who created a page. It’s not an issue if you’re targeting a normal Person property, which is why I’m only surfacing this concern in this section about creating new pages.

P.S. – If you want to full understand how permissions work, read my comprehensive guide to Notion sharing and permissions.

On the other hand, using the Access to submission will create a permission setting for that specific user on that specific page. This means that you (assuming you’re the database admin reading this) retain the ability to downgrade or remove the submitter’s access to each created page.

Best For Guests: Tally Form + Automation

Let’s say you’re running an agency, and you want to invite all your clients into your Notion workspace as guests so you can give each of them a Client Portal page, and so they can submit new requests.

Unfortunately, the Notion Forms solution above isn’t going to work for you. Notion Forms aren’t a workable solution for granting permissions to guests in your workspace.

This is due to the fact that guests cannot fill out a Form that has the default Who Can Fill Out setting of “Anyone in [your workspace] with the link”. This setting makes the Form internal-only, meaning only workspace members can fill it out.

You can change the Form’s permission to “Anyone on the web with the link”, which will make it public. This will allow workspace guests to fill it out – but the Created By property will be “Anonymous”, which makes it useless for granting permissions.

Luckily, there is a workaround!

In fact, it’s such a useful workaround that you might want to keep using it even if Notion fixes this page-creation problem in the future.

It’s a setup I created that:

• Requires only 10-20 minutes of initial setup
• Scales to an unlimited number of clients with very little work
• Can be set up for free (depending on which tools you choose)

Here’s the gist. On each client’s portal page, you embed a form built with a separate forms tool (I recommend Tally). When the client submits a request through this form, it passes their Notion user ID and the page ID of their portal page along as hidden values.

You then configure Tally to send the form submission to an automation tool, such as Pipedream, Zapier, or n8n. This is a relatively simple automation, so nearly any automation tool will work. For fun, I built this setup in five different tools – Pipedream, Zapier, Make.com, n8n, and Val Town.

The automation tool does what Tally can’t do through its built-in Notion integration. It takes the hidden user ID and page ID values in the form response, and uses them to set Relation and Person property values when creating a new page in a Client Requests database.

In this way, you can use an external form to ensure each new client request creates a Notion page that:

• Sets its Client Account property to your client’s guest account
• Sets its Client relation property to your client’s portal page

The result: 1-2 seconds after your client submits the form, they’ll see their request show up in a linked view of the Client Requests database within their portal page!

I’m currently working on a video that will demonstrate exactly how to set this up, and I’ll embed it below once it’s finished.

“Loophole” Method: Use a Notion Automation

There’s a second method that both members and guests can use to create new pages, and it’s Notion-native; it doesn’t require any third-party tools.

However, to me, it feels very much like a loophole, and I’m not 100% convinced it won’t be patched. That said, I’ll show you how it works!

I mentioned earlier that a user can’t click a Button that would create a new page in a database if they don’t have Can Edit Content (or higher) access to that database.

But that doesn’t stop a Notion automation from creating a new page… and a guest can trigger a Notion automation by editing a property on an existing page.

I’ll warn you that while testing this method, I did have one instance where my Notion workspace crashed after the new page was created by the automation. I had to use Notion search to find, and then delete, the newly-created page to get my workspace to show anything in the sidebar. So…. I’m not going into further detail about how to set this automation up, and I’d probably recommend not using it in any production workspaces.

I’m mostly mentioning this method in order to be thorough, and to simply make you aware that automations can create a way for guests to “create” new pages. You may want to be aware of this if you have existing automations that modify a Person property, and which might intersect with newly-created page-level access rules.

Granting Permissions Through Relations

Let’s say you’ve got a common two-database setup:

• Tasks
• Projects

You naturally want to create the same permissions setup that you’ve seen in other popular project management tools like Asana: If you grant a user access to a Project, they should get access to all Tasks within that Project.

As I mentioned in the Limitations section, this is tough to do since page-level access rules can’t target Rollup properties.

If they could, you could create a Rollup in your Tasks database that pulls a Project Members property (Person-type) from the Projects database.

But you can’t do that… so what can you do? You use automations.

Three automations, to be exact. You can create this type of “access via Relation” through a set of three automations. You also need a set of matching Person-type properties on both databases. In the example below, the Projects database has a Project Members property, which is used to set the value of a Project Access property on the Tasks database.

First, in your Projects database, you need an automation that:

• Triggers on a Project Members property being edited
• Defines a variable, which is the list of pages in the project page’s Tasks relation (this is all tasks related to the project)
• Edits the pages in that Tasks variable, replacing the contents of the Project Access property with the list of users in the Project Members property from the trigger page

Next, in your Tasks database, you need two automations.

You’ll need an automation that:

• Triggers when the Project relation is edited
• Defines a variable called Project Members, the value of which is the current value of the Project Members property in the related Project page
• Replaces the Project Access property in the current Tasks page with that variable’s list of users

Finally, you’ll need another Tasks automation that:

• Triggers when the Project relation is cleared
• Clears the Project Access tab

This setup almost works perfectly. Notably, the final automation won’t trigger if a Project page is deleted. Notion’s database automation engine doesn’t count this as an “edit” or “clear” action, so it can’t trigger anything.

I haven’t found a way to work around this so far, so keep it in mind. For now, if you use this set up, you’ll need to manually edit the permissions on Tasks if you delete a Project page.

Alternatives

If you want to create row-level access rules directly in Notion, there are no alternatives to this new page-level access feature. You’ll have to pony up for the Business plan and deal with its limitations.

But what you’re on the Plus plan – or even the Free plan – and can’t afford an upgrade right now? Or what if the limitations are deal-breakers for you?

This guide wouldn’t be truly comprehensive if I didn’t mention that you do have an alternative choice… if you’re willing to use Notion as a backend data source and build a separate interface on top of it.

The best-known tool for doing this right now is Softr, and they even have a full guide on building user-facing portals and apps that use Notion as a backend:

Turn Notion databases into portals and apps — no code required

Say hello to Notion as a data source in Softr! Create client and membership portals, directories, CRMs, inventory trackers, and more.

www.softr.io

Depending on your needs, and the number of users you need to serve, their plans may end up being more or less expensive than simply upgrading to Notion’s Business plan.

Note: In case you’re looking for alternatives due to the limitations around creating new pages, I’ll remind you that you can use my Tally Forms workflow detailed above to get around that limitation for free.

There are other tools that specialize in using Notion (and other sources) as back-end data sources for user-facing interfaces. Retool is another, though it seems more focused on helping folks create internal tools, where Softr is more focused on customer portals.

FAQs

Wrap-Up

If you enjoyed this article, you’ll also love my free Notion Tips newsletter. Get subscribed, and I’ll let you know when I publish new articles like this one – as well as free Notion templates!