Migrating Permissions from SharePoint to Notion: A Step-by-Step Guide

SharePoint permissions don't map to Notion permissions. Not partially, not roughly — the two platforms use fundamentally different access-control architectures. SharePoint enforces a hierarchical, inheritance-based model tied to Microsoft Entra ID with granular, item-level restrictions. Notion uses a flatter, workspace-driven model designed for default transparency and rapid collaboration.

If you attempt a one-to-one mapping of SharePoint's complex permission structures into Notion, you will break Notion's search, frustrate your users, and likely expose sensitive data. A successful migration translates effective access into a smaller, cleaner Notion model, then reapplies only the exceptions that still matter.

This guide covers the technical constraints, identity mapping requirements, and architectural strategies required to move your access controls safely. If you're looking for the broader content migration process, see our SharePoint to Notion Migration: The Complete Technical Guide.

Why SharePoint Permissions Don't Map to Notion

Before you start mapping roles, understand why a direct translation is impossible.

SharePoint's permission model is container-hierarchical. Permissions cascade from tenant policies down through site collections, sites, lists/libraries, folders, and individual items. Each level inherits from its parent unless inheritance is explicitly broken. The model is powered by Microsoft Entra ID groups, SharePoint groups, and seven default permission levels: Full Control, Design, Edit, Contribute, Read, View Only, and Limited Access. Microsoft allows up to 50,000 unique ACLs in a document library while recommending you stay under 5,000 for performance. (learn.microsoft.com)

Notion's permission model is workspace-flat with page-level overrides. A Notion workspace contains teamspaces, which contain pages. Pages inherit permissions from their parent teamspace or page, but any page can have its own sharing rules applied directly. Notion offers six page-level permission levels: Full Access, Can Edit, Can Edit Content (databases only), Can Create (databases only), Can Comment, and Can View. (notion.com)

Here is where the models diverge most sharply:

The last row kills automation plans. The Notion API lets you create pages, update properties, and manage content — but it does not expose any endpoint to share a page with a user or group, or to set permission levels programmatically. This is a hard platform limitation as of 2026. All permission mapping must be handled via SCIM group provisioning, teamspace architecture, and manual UI configuration.

Step 1: Audit and Export Your SharePoint Permission Structure

You cannot map what you haven't documented. Start by generating a complete inventory of every permission assignment across your SharePoint environment.

What to capture

For each SharePoint site in scope, you need:

• Site-level groups and members — who is in Owners, Members, Visitors, and any custom SharePoint groups
• Broken inheritance points — which lists, libraries, folders, or items have unique permissions
• Permission levels assigned — which groups or users have Full Control, Edit, Contribute, Read, etc.
• External/guest sharing — any content shared outside your organization
• M365 Group or Entra ID group memberships — the upstream identity source

If the source lives behind Teams, inventory private and shared channel sites separately: each channel gets its own SharePoint site, and permissions for those sites are managed in Teams rather than in SharePoint directly. (learn.microsoft.com)

How to extract it

Use the SharePoint REST API to pull role assignments per site, list, and item:

GET https://{tenant}.sharepoint.com/sites/{site}/_api/web/RoleAssignments?$expand=Member,RoleDefinitionBindings

For list-level permissions with broken inheritance:

GET https://{tenant}.sharepoint.com/_api/web/lists/GetByTitle('{listTitle}')/RoleAssignments?$expand=Member

You can also use the Microsoft Graph API for some permission data:

GET https://graph.microsoft.com/v1.0/sites/{siteId}/permissions

For most teams, PnP PowerShell is the fastest path to a full export:

Connect-PnPOnline -Url "https://tenant.sharepoint.com/sites/YourSite" -Interactive
 
# Export site group memberships and roles
Get-PnPSiteGroup | ForEach-Object {
    $group = $_
    Get-PnPGroupMember -Group $group.Title | ForEach-Object {
        [PSCustomObject]@{
            GroupName = $group.Title
            Roles     = ($group.Roles -join ", ")
            UserEmail = $_.Email
            UserName  = $_.Title
        }
    }
} | Export-Csv -Path "permissions_export.csv" -NoTypeInformation

Run this against every site in scope. The output is your permission source of truth — every decision from here flows from this CSV.

Surface broken inheritance

SharePoint environments with hundreds or thousands of items that have broken inheritance are common. Each one is a unique permission scope you need to evaluate individually.

Connect-PnPOnline -Url "https://tenant.sharepoint.com/sites/Operations" -Interactive
 
# Find lists with broken inheritance
$lists = Get-PnPList | Where-Object { $_.HasUniqueRoleAssignments -eq $true }
Write-Host "Lists with broken inheritance:"
$lists | Select-Object Title
 
# Find items with broken inheritance in a specific list
$items = Get-PnPListItem -List "Contracts" -PageSize 500
foreach ($item in $items) {
    if ($item.HasUniqueRoleAssignments) {
        Write-Host "Item ID $($item.Id) has unique permissions."
    }
}

Step 2: Collapse Permission Complexity Before Migration

Microsoft's own limits tell you when the source needs cleanup. SharePoint allows up to 50,000 unique ACLs in a library but recommends staying under 5,000, and once a folder, library, or list passes 100,000 items you cannot break or re-inherit permissions at that level. If your source depends on thousands of one-off exceptions, copying them into Notion will create either oversharing or an unmaintainable target. (learn.microsoft.com)

Reduce the model first. Typical cleanup moves:

• Replace direct user grants with group-based grants. This translates cleanly to Notion's group model.
• Merge near-identical ACLs into a single target audience. Two groups with the same effective access should become one.
• Treat Limited Access as plumbing, not a business role to migrate. It's normally traversal support that SharePoint creates automatically.
• Flag Everyone except external users, anonymous links, and existing-access links for redesign. These patterns have no Notion equivalent. (learn.microsoft.com)
• Separate governance controls from content permissions. SharePoint sensitivity labels, DLP policies, and restricted access control are not page-level permissions — they need their own target-state design. (learn.microsoft.com)

Audit your broken-inheritance items carefully. In practice, a significant percentage of item-level permission overrides are stale — shared with former employees, contractors who finished their project, or one-off shares that should have been revoked. Clean these up in SharePoint before migration to reduce the Notion configuration burden.

Step 3: Map SharePoint Groups to Notion Groups and Teamspaces

Do not migrate individual user permissions. Map groups to groups.

Notion's access control operates at two levels: teamspace membership (who can see an entire section of the workspace) and page-level permissions (who can do what on a specific page). Your SharePoint site-level groups map most naturally to Notion groups assigned to teamspaces:

Create your Notion groups first

Before migrating any content, build out your Notion group structure. Go to Settings → Members → Groups and create groups that mirror your SharePoint security groups. Name them consistently — Finance-Editors, HR-Viewers, etc.

SCIM provisioning for Enterprise

If you're on the Notion Enterprise plan, automate group management using SCIM:

1. Configure the Enterprise Application: In the Entra ID admin center, add Notion as an Enterprise Application. Configure SAML-based single sign-on (SSO).
2. Enable SCIM Provisioning: In Notion, navigate to Settings & Members → Identity & Provisioning. Generate a SCIM API token and input it into Entra ID provisioning settings.
3. Map Attributes: Ensure userPrincipalName maps to Notion's email attribute.
4. Sync Groups: Push your primary security groups (e.g., SG-Finance, SG-Engineering) into Notion.

Notion's SCIM integration supports Okta, OneLogin, Rippling, and Azure AD. Changes from the IdP overwrite edits made in Notion — exactly what you want when membership should be centrally controlled. (notion.com)

Build an identity mapping spreadsheet

Tie every source scope to a target:

source_scope,source_principal,source_role,target_teamspace,target_group_or_user,target_access,notes
HR site,HR Members,Edit,HR,@hr-editors,Can edit,group-based carryover
Finance library,Finance Reviewers,Read,Finance,@finance-viewers,Can view,collapsed from folder ACLs
Policies folder,All Employees,Read,Company Wiki,@all-hands,Can view,replaces Everyone except external users
Board packet,cfo@vendor.com,Read,Executive,guest:cfo@vendor.com,Can view,page-specific external access
Requests list,Operations Contributors,Contribute,Operations,db:Requests,Can edit content,database target

Decide early who should be a member, restricted member, or guest. Guests are page-scoped, cannot be added to groups, and SCIM cannot manage them. Restricted members are billed like members but can be placed into groups and teamspaces — use them for recurring, limited internal access. Use guests for narrow external access. (notion.com)

Step 4: Translate Permission Levels

SharePoint provides seven default permission levels. Notion provides six. You must map the complex to the simple. (learn.microsoft.com)

For databases, Can Create is worth considering. It lets contributors submit entries without browsing other records they haven't been granted access to — a better match for many SharePoint Contribute scenarios than broad edit rights. (notion.com)

When mapping roles, apply them at the highest possible level in Notion — the teamspace or top-level page. Let the permissions cascade down the page tree.

Step 5: Build the Notion Teamspace Structure

With your group-to-group mapping and permission-level mapping defined, create the target teamspace structure.

For each SharePoint site in scope:

1. Create a Notion teamspace with the appropriate visibility setting.
2. Add groups to the teamspace with the correct permission level. Teamspace owners set defaults for each group under the Members tab.
3. Set the teamspace default permission — this determines what non-members (workspace members) can do. For Closed teamspaces, set this to No Access or Can View depending on your policy.

Teamspace type decision matrix

For sensitive material (HR, Finance, Legal, executive content), start with a Private teamspace and add explicit groups. That is safer than trying to recreate deep item-level SharePoint exceptions one page at a time. For sensitive teamspaces, use Notion's security settings to disable guest access, disable public sharing, and — where appropriate — prevent exports before you bulk-load content. (notion.com)

Step 6: Handle Item-Level and Folder-Level Permissions

This is where migrations get painful. SharePoint allows unique permissions on any item — a specific document, a single list item, an individual folder. Every place where inheritance was broken is a unique permission scope.

Notion handles this differently. Every page can have its own sharing settings that override the parent. But the mechanism is manual — you open the Share menu and add people or groups with specific permission levels. There is no API to automate this.

This means:

• For small numbers of unique permissions (under ~50), manually configure each page's sharing after content migration.
• For large numbers (hundreds or thousands of broken-inheritance items), you must make a governance decision: flatten your permission model or accept a large manual effort.

Practical strategies for high-complexity environments

1. Use teamspace boundaries as permission boundaries. Instead of replicating item-level permissions, reorganize content so that permission boundaries align with teamspace boundaries. If the Finance team's confidential reports lived in a shared library with broken inheritance, move them to a Private Finance teamspace in Notion.

2. Split databases for mixed-sensitivity data. Suppose you have a SharePoint list called "Employee Directory." Most columns are visible to everyone, but the "Salary" column and specific executive rows have item-level restrictions. Because Notion does not support column-level security, you cannot migrate this list as-is.

Use the Split Database Pattern:

• Database A: "Employee Directory (Public)" — assigned Can View to the entire company.
• Database B: "Employee Compensation (Private)" — assigned Can Edit only to the HR group.
• Link them: Use a Notion Relation property to connect the public directory to the private compensation database. Only users with access to Database B will see the related financial data; for everyone else, the relation appears blank or inaccessible.

3. Use page-level access rules for database rows. On Business and Enterprise plans, Notion supports page-level access rules on databases. These let you grant row-level permissions based on a Person property. This is the closest Notion gets to SharePoint's item-level permissions on list items.

Watch for the "most permissive wins" behavior. When a user receives access through multiple paths, Notion keeps the most permissive access. If you set a broad teamspace rule and expect a lower page rule to restrict it, you will overshare. Apply permissions from the outside in: teamspace membership first, top-level pages second, page-specific exceptions last. (notion.com)

Step 7: Migrate External and Guest Access

SharePoint's external sharing model is rich — anonymous links, org-specific links, guest accounts tied to Azure AD B2B. Notion handles external access through guest invitations only.

Key differences:

• No anonymous sharing. Notion requires an email address for every guest. If you used anonymous links in SharePoint, those patterns cannot be replicated.
• Guest limits vary by plan. Plus allows 100 guests, Business allows 250, Enterprise allows unlimited. Exceeding the limit silently converts guests to paid workspace members.
• Guests can only access pages explicitly shared with them. There's no equivalent to SharePoint's site-level guest access. You must share each relevant page individually.
• Guests cannot be added to Notion groups, and SCIM cannot manage them. (notion.com)

Extract your external sharing data from SharePoint:

GET https://graph.microsoft.com/v1.0/sites/{site-id}/drive/sharedWithMe

Because the Notion API does not support managing guest invites, export this data to a CSV. Build a guest mapping table:

Invite each guest manually via the Share menu on the relevant Notion pages after content migration is complete. If your workspace uses guest requests, only workspace owners can approve them — per page, per guest. That process is slow in bulk, which is one more reason to minimize one-off external exceptions before cutover.

Step 8: Validate Permissions Post-Migration

Permission migration without validation is a security incident waiting to happen.

Positive testing (can they access what they should?)

• Pick 3–5 representative users from each permission tier (owners, editors, viewers, guests)
• Have each user log into Notion and verify they can see and interact with their expected content
• Test across teamspace boundaries — confirm they cannot see Private teamspaces they shouldn't access

Negative testing (can they access what they shouldn't?)

• Select users who had restricted access in SharePoint
• Verify they cannot see or edit content outside their scope in Notion
• Use Notion's global search to look for known sensitive keywords (e.g., "Payroll", "Termination"). If a test account with standard access can see these results, a permission has cascaded incorrectly.
• Check that former guests and external users don't have broader access than intended

Minimum test matrix

• One admin, one editor, and one viewer from every major audience
• One removed user who should now have no access
• One guest who should only see explicitly shared pages
• One database contributor who should edit records but not schema (if assigned Can Edit Content)
• One page equivalent from each high-risk broken-inheritance area

Build a validation spreadsheet

The last row illustrates a common gotcha: when you share a child page with a guest, the guest may see the parent page title in their sidebar (though not its content). This is expected Notion behavior, but it surprises teams coming from SharePoint's security-trimmed navigation where unauthorized content is completely invisible.

On Enterprise plans, Notion's audit log retains up to 365 days of history and lets you filter by date, person, event, and related actions. Use it during validation and cutover week, not after someone reports oversharing. You can also export audit events via CSV or stream them to a SIEM via webhooks. (notion.com)

Decommission SharePoint

Once access is validated, set the source SharePoint sites to ReadOnly. Do not delete the data immediately. Leave it in a read-only state for 30 days to ensure no critical workflows were broken during the transition.

Step 9: Set Up Ongoing Permission Management

The migration isn't done when the content lands. You need a system to manage permissions going forward.

For Enterprise plan workspaces:

• Configure SCIM provisioning through your identity provider. When someone joins or leaves a department in your directory, their Notion group membership updates automatically.
• This handles teamspace access. Page-level overrides still require manual management.

For Business plan workspaces:

• SCIM is not available. Manage groups manually in Settings → Members → Groups.
• Establish a quarterly permission review process — Notion doesn't have SharePoint's built-in access review workflows.

For all plans:

• Document your permission model. Write it down — which groups exist, what teamspaces they access, what the default permissions are, where page-level overrides exist.
• Assign a workspace owner as the permission administrator. This role doesn't exist natively — it's an operational discipline.

For a deeper look at SharePoint's permission hierarchy and security best practices, see our Definitive Guide to SharePoint Permissions & Security.

Common Failure Modes

Here are the failure modes we see most often in SharePoint-to-Notion permission migrations:

1. "We'll just give everyone Can Edit." Flattening permissions to save time creates security gaps. Teams that had View Only access in SharePoint suddenly have edit rights. For compliance-sensitive content (HR, legal, finance), this is a non-starter.

2. Landing content in default teamspaces. Everyone in the workspace automatically has access to default teamspaces. Sensitive migrated content must go into Closed or Private teamspaces.

3. Ignoring broken inheritance during audit. If you don't enumerate every unique permission scope in SharePoint, you'll miss items that should be restricted in Notion. A single confidential document accessible to the wrong group can be a compliance violation.

4. Assuming SCIM handles everything. SCIM syncs users and groups. It does not configure teamspace permissions or page-level sharing. Those are separate steps that must be done manually or through workspace settings.

5. Hitting Notion's guest limit mid-migration. If your SharePoint environment has heavy external sharing, count your external users before starting. Exceeding Notion's guest limit silently converts guests to paid workspace members.

6. Not testing negative access. Verifying that users can see their content is easy. Verifying that they can't see restricted content requires deliberate test cases with restricted accounts.

7. Expecting the API to set permissions. Notion's API handles content, not sharing. Most production migrations automate content creation via the API and user/group provisioning with SCIM, but handle page and teamspace sharing through admin workflows. The API is also rate-limited to an average of three requests per second per connection. (developers.notion.com)

When to Get Help

Permission migrations between platforms with incompatible models are inherently high-risk, low-visibility work. The content migration might be automatable, but permissions require human judgment at every translation point — especially when Notion's API doesn't support programmatic sharing.

If your SharePoint environment has more than a handful of sites, heavy use of broken inheritance, complex external sharing requirements, or compliance requirements around access control, the cost of getting permissions wrong far exceeds the cost of getting expert help.