SharePoint Permissions: Levels, Groups & Inheritance

Our SharePoint permissions support cases follow a pattern: a site that started with three groups accumulates years of one-off sharing and broken inheritance, and nobody can state who has access to what. This page documents the permission model itself — levels, groups, inheritance, sharing links — and the tools for auditing it.

Permission levels

A permission level is a named bundle of individual permissions (View Items, Add Items, Manage Lists, and so on). Users and groups are assigned levels, not individual permissions. The defaults, per the official reference:

Publishing sites add Approve, Manage Hierarchy, Restricted Read, and View Only. All default levels except Full Control and Limited Access can be edited, and custom levels can be created — both are rarely worth the audit complexity they add.

Default groups

Every site carries three default SharePoint groups, each mapped to one level:

Groups can contain individual users, Microsoft Entra security groups, or both. Assigning security groups to the three SharePoint groups, and managing membership in Entra ID, is the pattern that stays auditable at scale. Granting levels to individual users directly on the site bypasses the groups and is the first thing that makes a permissions report unreadable.

Group-connected team sites

Modern team sites are connected to a Microsoft 365 group, and the group drives access: group owners become site owners and group members become site members. Adding someone to the Microsoft 365 group — from Outlook, Teams, or the admin center — grants them the site, the mailbox, and the other group services in one step. Group owners are additionally made site collection administrators on the connected site.

The flow is one-directional. Adding a user to the SharePoint Owners group does not make them a Microsoft 365 group owner, and users added directly to SharePoint groups get the site only, not the mailbox or Teams. Microsoft 365 groups have no read-only tier, so view-only users must be added to the site Visitors group directly. For sites backing a Teams team, manage membership in Teams; for private and shared channel sites, SharePoint permission management is read-only and Teams is the only control surface. Communication sites have no group connection and use the three SharePoint groups alone.

Inheritance

Permissions flow down the hierarchy: site, then library or list, then folder, then item. By default every object inherits from its parent, so one assignment at the site level covers everything below it. Any object can break inheritance — Library settings, Permissions for this document library, Stop Inheriting Permissions, or Manage access and then Advanced on a folder or file — after which it carries its own access control list, and changes at the parent no longer reach it.

Every break creates a unique permission scope that has to be audited separately. At scale the model degrades in documented ways, per the SharePoint limits and the too-many-items troubleshooting page:

• The supported limit is 50,000 uniquely permitted items per list or library; the recommended general limit is 5,000, because bulk changes across more uniquely permitted items than that slow down markedly.
• When a list, library, or folder contains more than 100,000 items, inheritance can no longer be broken or re-inherited on that container at all — only on individual items within it.
• Each shared item inside a folder with broken inheritance is its own scope: a folder plus two individually shared files costs three scopes, even when the access lists are identical.

The design rule that follows: structure content so that permission boundaries fall on sites and libraries, not folders and items. A separate site with its own membership is cheaper to operate than a shared library with a hundred broken-inheritance folders. Note that every "share" of an individual file by a user is a broken-inheritance event — item-level sprawl accumulates without any administrator touching permission settings.

Sharing links

File and folder sharing in SharePoint and OneDrive works through links, documented in the shareable links reference:

Administrators control which types exist and which is the default, at the organization level and per site, in the SharePoint admin center under Policies, Sharing — see manage sharing settings. External sharing has four organization settings — Anyone, New and existing guests, Existing guests, Only people in your organization — and a site cannot be more permissive than the organization. Setting the default link to Specific people while leaving broader types available reduces accidental wide grants without blocking legitimate sharing. Guest access expiration can be enforced in days.

Checking who has access

Three places, in order of specificity:

1. Check Permissions on a single user. Site Settings, Site permissions, Check Permissions on the ribbon (or Advanced permissions settings on modern sites). Enter a user or group name; the result lists their effective permission levels on that object and which group membership grants each one. This is the answer to "why can this person see this."
2. The site permissions pages. Site Settings, Site permissions shows the top-level assignments; each library or folder with broken inheritance has its own permissions page reachable from its settings. Objects with unique permissions display a banner stating that they do not inherit.
3. Manage access on an item. Shows the direct grants and every active sharing link on that file or folder, with the option to delete links individually.

Tenant-wide, the SharePoint admin center provides Data Access Governance reports: sharing-link reports (Anyone, People in your organization, Specific people links created), sensitivity-label reports, and the site permissions snapshot report, which exports per-site counts of permissioned users, guest permissions, items with unique permissions, Anyone links, and Everyone-except-external-users grants — the direct measure of oversharing per site. From DAG report results, admins can initiate site access reviews, which assign the affected site owners a review task to reattest or trim access. Most DAG reporting requires SharePoint Advanced Management or a Copilot license on the tenant.

Common permission incidents

• Broken-inheritance sprawl. Years of item-level sharing leave thousands of unique scopes nobody can enumerate. Symptom: sharing fails with "too many items with unique permissions," or permission reports time out.
• Orphaned unique permissions. A folder was broken out for a project; the project ended, the people left, the scope remains and still grants access. Nothing at the site level shows it.
• Everyone except external users surprises. Content granted to this built-in claim is visible to the entire organization — and surfaces in organization-wide search and Copilot results. The DAG snapshot report counts these grants per site for exactly this reason.
• Lost site owner. The only owner left the company. For group-connected sites, a Microsoft 365 admin assigns a new group owner; for others, a SharePoint administrator adds a site collection administrator from the admin center.
• Members can edit permissions. On sites where the default was changed so Members hold Full Control, or where "members can share" settings are wide open, membership equals ownership in practice.

Cleanup approach

1. Export the DAG site permissions snapshot report and rank sites by items with unique permissions, Everyone-except-external-users count, and Anyone link count.
2. Per site: record the current state before changing anything — group memberships, direct grants, and every object listed as uniquely permissioned.
3. Remove direct user grants at the site level; move those users into the appropriate group or drop them.
4. Re-inherit permissions on folders and items whose unique scopes no longer serve a purpose. Delete stale sharing links from Manage access.
5. Where a folder genuinely needs different access than its library, evaluate moving it to its own site or library instead of keeping the broken scope.
6. Set the site default sharing link to Specific people and confirm the external sharing setting matches the site's actual need.
7. Re-run the snapshot report after 48 hours to confirm the counts moved, and schedule access reviews for the sites that stay high.

Related pages: SharePoint document library for library-level settings that interact with permissions, and SharePoint admin center for the tenant-level controls referenced above.