How to Set Up Row-Level Permissions in Notion Databases

After years of eager anticipation, Notion has finally delivered one of its most requested features: row-level database permissions. This powerful capability allows you to control who can access specific pages within your databases, solving a pain point that had some users almost quitting the platform entirely.

“Finally. I don’t need to duplicate my product list to delete the ‘cost’ property for customer’s preview,” as one user eloquently put it. If you’ve been waiting for a more sophisticated way to segment database access among team members or external stakeholders, your patience has paid off.

Understanding Notion’s Database Permission Levels

Before diving into row-level permissions (officially called “page-level access” in Notion), it’s important to understand the core permission levels available in Notion databases:

• Full access: Users can edit everything, including database structure, properties, views, filters, sorts, and permissions
• Can edit: Users can create and edit pages within the database
• Can edit content: This is the game-changer permission level that allows users to edit page content without modifying the database structure
• Can comment: Users can only view and comment on pages
• Can view: Read-only access

The “Can edit content” permission is particularly valuable as it keeps your database structure intact while allowing collaborators to work with the content. This prevents team members or clients from accidentally breaking views or deleting critical properties.

Setting Up Page-Level Access: Step-by-Step Guide

Important Note: Native row-level permissions require a Notion Business or Enterprise plan. If you’ve been eagerly waiting for this feature, it might be time to upgrade.

Here’s how to implement page-level access in your Notion databases:

1. Navigate to the full-screen page of your database (not a linked view)
2. Click the Share button in the top-right corner
3. First, invite the relevant people or groups and set their base permission level (typically “Can edit content”)
4. Inside the Share menu, locate the Page-level access section
5. Click Create a rule
6. Configure your rule with:
   • A condition based on a property (currently only Person and Created by properties are supported)
   • An access level defining what matching users can do with the pages

If multiple rules apply to a single page for the same user, the highest access level will apply.

Real-World Use Case: Team Task Management

Let’s implement database segmentation for a team task tracker:

1. Ensure your task database has a Person property named “Assignee”
2. Share the database with your team, giving them “Can view” access at the database level
3. Create a page-level access rule:
   • If “Assignee” contains “Person viewing the page”
   • Then “Person viewing the page” can “Edit”

This configuration allows team members to see all tasks in the database but only edit the ones assigned to them. For a personalized experience, create a linked database view on each team member’s personal page with a filter where “Assignee is @me”.

Real-World Use Case: Client Project Portal

For agencies and consultants who’ve been eagerly waiting for better client collaboration tools, this feature is a game-changer:

1. Create a database with all your client projects
2. Include a Person property for “Client Contact”
3. Invite clients as guests with “Can view” base access
4. Create a page-level access rule:
   • If “Client Contact” contains “[Client’s name]”
   • Then “[Client’s name]” can “Comment” or “Edit” (depending on your workflow)

This setup ensures clients only see their own projects, not those of other clients. You no longer need to duplicate your entire product list just to hide sensitive information from clients.

Key Limitations of Row-Level Database Permissions

While this feature drop is significant, it’s important to understand its limitations:

1. No Direct Page Creation: Users with only rule-based access (without “Can edit content” at the database level) cannot create new pages/rows in the database.
2. No Deletion Rights: Even with “Full access” to a specific page via a rule, users cannot delete that page without broader permissions at the database level.
3. Limited Property Support: Rules only work with Person and Created by properties. You cannot create rules based on Select, Status, or Relation properties.
4. No Column-Level Security: This is crucial to understand—page-level access lets you hide entire rows, but not specific columns within a visible row. If a user can see a page, they see all its properties. This explains why some users previously had to “duplicate my product list to delete the ‘cost’ property for customer’s preview.”

Many users who have been waiting for this feature might be disappointed by these limitations, especially the inability to hide specific columns from certain users.

Advanced Workarounds for True Granular Control

When native features don’t provide enough flexibility, consider these workarounds:

Using Forms to Bypass Creation Limits

For team members or clients who need to add entries but shouldn’t see the entire database:

1. Create a Notion Form connected to your database
2. Share just the form link with limited-access users
3. They can submit new entries without accessing the database directly

For external stakeholders, third-party tools like Tally or NoteForms can connect to your Notion database while providing even more customization options.

Using the Notion API and Automation for Column-Level Security

For true property-level security (hiding specific columns like “cost”):

1. Maintain a “private” master database with all data
2. Use automation tools (Make, Zapier) to sync only non-sensitive properties to a “public” database
3. Share only the “public” database with clients or team members needing limited access

This approach provides genuine column-level security but requires technical setup and may involve costs for automation tools.

Client Portals with Third-Party Front-End Builders

For the most sophisticated solution:

1. Use Notion as a backend database
2. Build a custom client portal using tools like NotionApps or Softr
3. Configure granular permissions in the front-end builder:
   • Row-level filtering based on user email or other identifiers
   • Column visibility controls to hide sensitive information
   • Custom forms for data entry

This approach offers the most control but comes with additional costs and a learning curve.

Troubleshooting Common Access Issues

Here are solutions to common problems you might encounter when implementing row-level permissions:

“A user can’t see a page they are assigned to”

Double-check the page-level access rules in the original database (not a linked view). Ensure the Person property on that specific page correctly contains their user profile. Remember that rules don’t work in offline mode, so connectivity issues might affect access.

“A guest can’t add new entries to our shared projects list”

This is expected behavior. Guests with limited access cannot create pages without “Can edit content” permission at the database level. Consider using forms as described above or granting slightly higher permissions with careful page-level restrictions.

“I gave a user ‘Full access’ in a rule, but they still can’t change a database view”

Rule-based permissions apply only to the content of specific pages. Structural changes (views, properties, filters) are governed by database-level permissions. The user needs “Full access” at the database level to make those changes.

Getting Started with Row-Level Permissions

If you’re eager to join the beta or access this feature:

1. Ensure you’re on a Business or Enterprise plan
2. Contact Notion support to inquire about betas for ambassadors if the feature isn’t already available to you
3. Start with a simple use case like a personal task manager to get comfortable with the feature

Conclusion

Notion’s row-level database permissions represent a significant step forward for collaboration and data security within the platform. While not perfect (especially for those wanting true column-level security), this feature enables much more sophisticated database segmentation than was previously possible.

For teams managing multiple projects, departments sharing resources, or consultants working with various clients, these new permission controls allow for cleaner, more secure collaboration without the need for duplicate databases.

If you’ve been eager to implement more granular access controls in your Notion workspace, now’s the time to start experimenting with these powerful new capabilities. And if you need even more control, consider the advanced workarounds outlined above to create truly customized experiences for your team and clients.

The Notion community has been waiting years for this feature, and while it may not solve every permission challenge, it’s a welcome addition that addresses many common use cases for database segmentation and access control.

Frequently Asked Questions

What are row-level permissions in Notion?

Row-level permissions, officially called “page-level access” in Notion, allow you to control which users can view, comment on, or edit specific pages (rows) within a single database based on rules you set. This feature is a significant enhancement for collaboration, as it enables you to share one database with multiple people while segmenting access to its content. For example, you can ensure team members can only edit tasks assigned to them, or that clients can only see project pages relevant to their account.

Why can’t I use page-level access in my Notion database?

Page-level access (row-level permissions) is exclusively available on Notion’s Business and Enterprise plans. If you are on a Free or Plus plan, you will not have access to this feature. This is a premium feature designed for teams and organizations that require more granular control over data access. If this capability is crucial for your workflow, you may need to consider upgrading your Notion subscription.

How can I hide specific columns (properties) from users in a Notion database?

Notion’s native page-level access does not support hiding specific columns (properties); it only controls access to entire rows (pages). If a user can see a page, they can see all of its properties. To achieve true column-level security, you need to use advanced workarounds, such as maintaining a private master database and using automation tools like Make or Zapier to sync only non-sensitive properties to a separate “public” database that you share with users.

What are the main limitations of Notion’s page-level access feature?

The primary limitations are the inability to hide specific columns (no column-level security), the restriction of rules to only ‘Person’ and ‘Created by’ properties, and the fact that users with only rule-based access cannot create or delete pages. Understanding these constraints is key to implementing the feature effectively and knowing when to use a workaround.

How can users add new pages if they don’t have full edit access to the database?

Users without “Can edit content” permission at the database level cannot create new pages directly. The recommended workaround is to use a form tool, such as Notion Forms or a third-party service like Tally, that is connected to the database. By sharing a form link, you allow users to submit new entries, which then appear as new pages in your database, bypassing the need for direct creation permissions.

Can I set permissions based on a ‘Status’ or ‘Select’ property?

No, you cannot set page-level access rules based on ‘Status’, ‘Select’, ‘Relation’, or other similar properties. Currently, the rules for page-level access can only be configured using the Person and Created by properties. This means permissions must be tied directly to the users who are assigned to or who created the page.