How to automate access in Notion databases (build client portals & more)
Note: This feature is only available on the Business and Enterprise Plan.
Note #2: On person properties in Notion, you can turn off user notifications via the property settings.
Note #3: Page creation for guests who use the page-level access rule is not supported yet. Guests can only create pages via a public Notion form. This has some limitations, and there are solutions. More on this at the end of the essay.
TLDR
https://www.notion.com/help/sharing-and-permissions?#database-page-level-access
Page-level access lets you grant per-row permissions via a
person/created byProperty on Business or Enterprise; rules apply across all views and per data source; people get notified by default (groups don’t).Setup: open source database → Share → Page-level access → Add a new rule → pick person/created by property → pick access → Create rule; add more rules as needed. If a database contains multiple data sources, you can set rules for each data source via the dedicated dropdown.
Behavior and caveats: if they already have DB access, rules add to it; without DB access, they work via notification or a linked view you share; they can’t create new pages without a form; broadest access wins; permissions inherit to subpages; private move removes others on parent only; “Anyone with link” can leak via mentions, two-way relations, or broader parents; delete rules from Share → rule menu.
Broadest access wins: if someone gets higher access anywhere else (like the whole database or workspace), that higher access overrides stricter page-level rules; always check the Share menu for broader grants.
Private doesn’t cascade: moving a shared page into your Private area removes others from that parent, but any subpages keep whatever sharing they already had; review subpages if you need them locked down too.
“Anyone with link” can spread: even without sending the link, access can leak if the page is mentioned on a widely shared page, linked via a two-way relation to a shared page, or nested under a broadly shared parent.
At the Make With Notion 2025 Conference, I was talking with Mike, who is a partner at a large innovative construction firm in San Francisco.
He works with lots of contractors and manages clients.
He wants to automate access for his clients and contractors, so they can only see their relevant projects and tasks on their Notion dashboard. This would be very valuable for him, because currently he is particularly overwhelmed with all the emails back and forth all day long. A centralized place to coordinate everyone’s work would be a fantastic step forward, reducing his admin overload significantly, he believes.
Until now, this was not possible (without some clunky workaround often using third-party tools).
Now, this is mostly possible. Here is a way to do it.
A diagram depicting the data structure and workflows involved
Clients Data Source
Create a “Clients” data source (or use your existing one). This is the central Data Source where you store all your client data. Each client page can become the client-facing portal if you wish. You can keep any client data here, and optionally a Person property to specify which client users are invited to your Notion workspace and have access to their page (let’s call this property “Users” in this post — remember this as you read below because I will mention this property).
The “Clients” data source will include a Client template (a dashboard) with linked views of Projects and Tasks, among any other information you wish.
Projects Data Source
A second data source we need is “Projects”. Here, you will create and manage all your client and internal projects. It’s the source of truth for all your company initiatives. This data source is linked to “Clients” via a Relation property, so that for each project, you can select the relevant client (or leave it empty if it’s an internal initiative).
Importantly, the Projects data source contains at least one Person property type, which you will use to set page-level access rules. Here is an example of Person properties you could have:
Owner — the user who leads the project
Team — the team/users responsible for working on the project (you may leverage Notion’s user groups for smoother management)
Client users — the client user(s) who will have access to the Project. This property can be populated automatically if you set the client users on the Client pages, as written in the previous section. You can create a database automation in “Projects”, with the following flow:
When Client is edited
Edit property: “Client users” (use a formula that maps the users from the related Client property—here is the pseudo-code:
Client.map(current.Users))
Finally, we create a page-access rule on the “Projects” data source. Anyone in the “Client users” property get editing/commenting/viewing access (pick your most suitable option). This ensures that whenever we create a project for our client, they will see it on their dashboard immediately and automatically.
Tasks Data Source
Next, there are Tasks. These are the action items related to Projects with an assignee and deadlines. Who does what by when. Tasks are related to Projects. One task, one project. Similar to the concepts I wrote above regarding Projects, Tasks will have a page-level access rule too. There could be two Person properties in the Tasks database:
Assignee — the user who is responsible for the completion of the task.
Client users — the client user(s) who will have access to the task. We can populate this property via an automation in the Tasks data source, with the following flow:
When Project is edited
Edit property: “Client users” (use a formula that maps the users from the Client related to the project—here is the pseudo-code:
Project.map(current.Client).map(current.Users))
Finally, we create a page-access rule on the “Tasks” data source. Anyone in the “Client users” property get editing/commenting/viewing access (pick your most suitable option). This ensures that whenever there is a task our client must see/edit, it will appear on their dashboard immediately and automatically.
A Note on Page Creation
Users who get editing access via a page-level rule can’t create pages directly in the database. To allow page creation, we can use a form. If you want guests to create pages or submit requests, the Form must be publicly shared, not just within the workspace, but publicly. When a guest submits a Form, their user doesn’t get tracked, which can be a hiccup.
This is a current limitation for some use cases, yes. There are solutions, for example using a third-party form tool (e.g., Tally, Typeform) with URL parameters to track the users who need access to the new pages created via the form.
