Notion Row-Level Permissions Automation
An automated workflow system built on n8n that manages row-level access permissions across multiple Notion databases.
Overview
The system automatically grants and revokes user access to Notion pages based on organizational membership, eliminating manual permission management while maintaining a complete audit trail.
Start with the APT Template and get the Free Workflow
This automation was built for the Xylo APT Productivity Kit. Using the template gives you the required database structure out of the box, making implementation straightforward.
Workflow available for free in our community chat: Xylo n8n workflow for row level permissions.
Problem Solved
Notion's native sharing model operates at the database or workspace level, not at the individual page (row) level. Organizations needing to share specific pages with external clients or team members based on organizational relationships had to manually manage the "Client Access" people property on every page—an error-prone and time-consuming process.
This automation solves that by:
- Automatically detecting new pages and organizational assignments
- Granting appropriate users access based on predefined mappings
- Handling user onboarding (Pending → Active) with full historical backfill
- Processing access revocation when users leave or permissions change
- Maintaining audit trails for compliance and troubleshooting
Key Features
Automatic Access Granting
- Detects new pages created in any of 7 monitored databases
- Detects when Organization is added to existing pages
- Automatically populates the Client Access field with appropriate users
- Supports both immediate (Active) and onboarding (Pending) user states
Intelligent Onboarding Flow
- New users start with "Pending" status in the mapping database
- System performs full organizational scan to grant access to ALL existing pages
- Automatically transitions users from "Pending" to "Active" after initial sync
- Eliminates manual backfill when onboarding new client users
Access Revocation
- Setting a mapping to "Revoked" triggers automatic removal from all pages
- Full organizational scan ensures complete access removal
- Mapping transitions to "Inactive" for audit trail preservation
- No manual cleanup required
Multi-Database Support
The system monitors 7 Notion databases simultaneously:
- Tasks - Project tasks and action items
- Notes - Working documents and meeting notes
- Meetings - Meeting records and agendas
- Resources - Reference materials and documentation
- Projects - Project records
- Work Log - Time tracking and activity logs
- Contacts - CRM contact records
Performance Optimization
- Incremental queries for routine operations (only pages updated since last run)
- Full organizational scans only triggered when Pending or Revoked users exist
- Deduplication prevents redundant API calls
- Efficient status-based branching minimizes unnecessary processing
Technical Architecture
Infrastructure
| Component | Technology |
|---|---|
| Platform | n8n (self-hosted community edition) |
| Hosting | Digital Ocean Droplet |
| Database Integration | Notion API v1 |
| Scheduling | Configurable interval (default: hourly) |
Workflow Components
Trigger Layer
- Manual trigger for testing and ad-hoc runs
- Scheduled trigger for automated execution (hourly at :45)
State Management
- Dedicated Notion database tracks workflow state
- Stores last successful run timestamp
- Enables incremental processing
Data Collection Layer
Incremental Branch (7 Notion nodes)
- Queries each database for pages updated since last run
- Uses native Notion node for simplified configuration
- Filters:
Updated >= lastRun
Full Organization Scan Branch (7 HTTP Request nodes)
- Triggered only when Pending or Revoked users exist
- Queries all pages for affected organizations
- Uses HTTP nodes for dynamic filter construction
Processing Layer
Mapping Resolution
- Retrieves all user-organization mappings
- Builds lookup tables: Organization → Users
- Filters by status (Active/Pending for grants, Revoked for removals)
Page Matching
- Matches pages to users based on Organization relation
- Calculates required Client Access updates
- Handles deduplication across branches
Update Layer
Access Grants
- Updates Client Access property on matched pages
- Updates mapping status (Pending → Active)
- Records grant timestamp
Access Revocations
- Removes revoked users from Client Access
- Transitions mapping status (Revoked → Inactive)
- Preserves audit trail
State Persistence
- Updates workflow state with completion timestamp
- Enables clean incremental processing on next run
Data Flow Diagram
┌─────────────────────────────────────────────────────────────────────────────┐
│ TRIGGERS │
│ Manual Trigger / Schedule Trigger │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────────────────┐
│ STATE RETRIEVAL │
│ Get Workflow State → Extract Last Run Timestamp │
└─────────────────────────────────────────────────────────────────────────────┘
│
┌─────────────────┴─────────────────┐
▼ ▼
┌───────────────────────────────────┐ ┌──────────────────────── ───────────┐
│ INCREMENTAL QUERIES │ │ USER ACCESS MAPPINGS │
│ 7 Notion Nodes (Updated>=Last) │ │ Get All Org→User Mappings │
│ Tasks/Notes/Meetings/Resources/ │ └───────────────────────────────────┘
│ Projects/Work Log/Contacts │ │
└───────────────────────────────────┘ ┌─────────────┼─────────────┐
│ ▼ ▼ ▼
│ ┌──────────────┐ ┌──────────────┐ ┌──────────┐
│ │Check Pending │ │Check Revoked │ │ Merge │
│ └──────────────┘ └──────────────┘ │ with │
│ │ │ │ Pages │
│ ▼ ▼ └──────────┘
│ ┌──────────────┐ ┌──────────────┐ │
│ │IF hasPending │ │IF hasRevoked │ │
│ └──────────────┘ └──────────────┘ │
│ │ │ │
│ TRUE │ TRUE │ │
│ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │7 HTTP Nodes │ │7 HTTP Nodes │ │
│ │Full Org Scan │ │Full Org Scan │ │
│ └──────────────┘ └──────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Normalize │ │ Normalize │ │
│ │ Pages │ │ Pages │ │
│ └──────────────┘ └──────────────┘ │
│ │ │ │
└──────────────────┤ │ │
▼ │ │
┌──────────────┐ │ │
│ Merge All │ │ │
│ Pages │◄────────┘ │
└──────────────┘ │
│ │
▼ │
┌──────────────────────────────────────────┐
│ MATCH PAGES TO USERS │
│ Build org→users lookup, match pages │
└──────────────────────────────────────────┘
│
┌──────────────────┴──────────────────┐
▼ ▼
┌───────────────────────────────────┐ ┌───────────────────────────────────┐
│ GRANT ACCESS │ │ REVOKE ACCESS │
│ Update Client Access (add users) │ │ Update Client Access (remove) │
│ Update Mapping → Active │ │ Update Mapping → Inactive │
└───────────────────────────────────┘ └───────────────────────────────────┘
│ │
└──────────────────┬──────────────────┘
▼
┌──────────────┐
│Update State │
│ Timestamp │
└──────────────┘
Database Requirements
Required Properties per Content Database
Each monitored database (Tasks, Notes, Meetings, etc.) must have:
| Property | Type | Purpose |
|---|---|---|
| Organization | Relation | Links to Organizations database |
| Client Access | People | Stores users with row-level access |
User Access Mapping Database Schema
| Property | Type | Purpose |
|---|---|---|
| Name | Title | Display name for the mapping |
| Notion User | People | The user to grant access |
| Organization | Relation | Which organization's pages to access |
| Status | Status | Active, Pending, Revoked, Inactive |
| Date Granted | Date | When access was granted |
| Date Revoked | Date | When access was revoked (if applicable) |
| Last Synced | Last Edited Time | Automatic timestamp |
Status Lifecycle
┌─────────┐ Workflow ┌─────────┐
│ Pending │ ───processes───▶ │ Active │
└─────────┘ └─────────┘
│
User removed
│
▼
┌─────────┐ Workflow ┌──────────┐
│ Revoked │ ───processes───▶ │ Inactive │
└─────────┘ └──────────┘
Workflow State Database Schema
| Property | Type | Purpose |
|---|---|---|
| Name | Title | Workflow identifier |
| Last Run | Date | Timestamp of last successful execution |
Use Cases
New Page Creation
Scenario: Team member creates a new Task linked to "Acme Corp" organization
Result: Client users mapped to Acme Corp automatically receive Client Access within the next scheduled run
Organization Assignment
Scenario: Existing Note is updated to link to "Acme Corp" organization
Result: Client users receive access on next run (caught by Updated >= lastRun filter)
New Client Onboarding
Scenario: New client user "Jane" is added to User Access with Status = "Pending" for "Acme Corp"
Result:
- System detects Pending user
- Full scan retrieves ALL Acme Corp pages across all 7 databases
- Jane receives Client Access on every page
- Status automatically updates to "Active"
Access Revocation
Scenario: Client "Jane" leaves Acme Corp, admin sets mapping Status to "Revoked"
Result:
- System detects Revoked user
- Full scan retrieves ALL Acme Corp pages
- Jane is removed from Client Access on every page
- Status automatically updates to "Inactive" (preserved for audit)
Routine Maintenance
Scenario: Hourly scheduled run with no Pending/Revoked users
Result:
- Incremental queries check only recently updated pages
- Any new/modified pages get appropriate access
- Minimal API usage, fast execution
Configuration
Schedule
- Default: Every hour at :45
- Configurable via n8n Schedule Trigger node
API Authentication
- Notion Internal Integration token
- Stored securely in n8n credentials
Monitored Databases
| Database | ID |
|---|---|
| Tasks | Your DB id here |
| Notes | Your DB id here |
| Meetings | Your DB id here |
| Resources | Your DB id here |
| Projects | Your DB id here |
| Work Log | Your DB id here |
| Contacts | Your DB id here |
Limitations & Considerations
Current Limitations
- Single Organization per Page: Pages linked to multiple organizations only process the first one
- Single Notion Workspace: Designed for single workspace deployment
- People Property Requirement: Target databases must use People property type for Client Access
Performance Considerations
- Full org scans query all pages for affected organizations
- Large organizations with many pages may experience longer processing times
- Recommend off-peak scheduling for large deployments
Security Notes
- Integration requires read/write access to monitored databases
- User Access Mapping database should be restricted to admins
- Audit trail preserved via Inactive status (not deletion)
Future Enhancements
- Multi-Organization Support: Handle pages linked to multiple organizations
- Webhook Triggers: Real-time processing via Notion webhooks (when available)
- Notification System: Alert admins on grant/revoke actions
- Bulk Operations Dashboard: UI for managing large-scale permission changes
- Cross-Workspace Support: Extend to multiple Notion workspaces
- Custom Field Mapping: Configurable property names per database
Technical Stack Summary
| Component | Technology |
|---|---|
| Automation Platform | n8n Community Edition (self-hosted) |
| Hosting | Digital Ocean Droplet |
| Database | Notion |
| API | Notion API v1 (2022-06-28) |
| Authentication | Notion Internal Integration |
| Scheduling | n8n Schedule Trigger |
Need this automation for your team? Contact us via support chat to discuss implementation.