All about SharePoint Permission Roles

SharePoint ships with ten built-in permission levels — Full Control down to Restricted Read — covering most access-control scenarios without needing a custom permission level. Here’s what each one actually grants, and how to assign them via PowerShell in both SharePoint Online and on-premises.

In this post: The ten built-in permission levels · Assigning a role in SharePoint Online · Assigning a role on-premises · Online vs. on-premises permissions · Best practices · When would you actually use this? · Related reading

The ten built-in permission levels

Full Control — everything, including managing permissions themselves. Reserve this for actual site owners/admins, not “whoever needs edit access.”
Design — create and modify pages, lists, and libraries, without full administrative control.
Edit — add, edit, and delete lists, and manage list content — more than Contribute, less than Design.
Contribute — add, edit, and delete list items, but can’t manage the list structure itself. This is the level most regular content contributors actually need.
Read — view-only access to site content.
View Only — can view but not download documents — narrower than Read, useful when content needs to stay viewable in-browser only.
Limited Access — granted automatically (not assigned directly) when someone needs access to one specific item within a site they don’t otherwise have broader access to.
Approve — can approve content in libraries with content approval workflows enabled.
Manage Hierarchy — create and delete sites, manage site settings, without the full scope of Full Control.
Restricted Read — can view pages and documents, but not version history or downloads — the tightest read-only option.

The two people get wrong most often: Contribute vs. Edit (Edit adds the ability to manage the list/library structure itself, not just its content), and Limited Access, which you’ll see appear on users automatically — it’s not something to assign directly, it’s what SharePoint grants so someone can reach a specific item they’ve been given access to, without exposing the rest of the site around it.

Assigning a role in SharePoint Online

Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/YourSite" -UseWebLogin

# Grant Read access to a group
Set-PnPGroupPermissions -Identity "Your Group Name" -AddRole "Read"

# Multiple roles at once
Set-PnPGroupPermissions -Identity "Your Group Name" -AddRole @("Contribute", "Design")

Assigning a role on-premises

The on-premises object model is more verbose — no PnP shortcut cmdlet, so you’re working directly with the SharePoint Server API:

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

$web = Get-SPWeb "http://yoursharepointsite"
$group = $web.SiteGroups["Your Group Name"]
$roleDef = $web.RoleDefinitions["Read"]
$roleAssignment = New-Object Microsoft.SharePoint.SPRoleAssignment($group)
$roleAssignment.RoleDefinitionBindings.Add($roleDef)
$web.RoleAssignments.Add($roleAssignment)
$web.Update()

Contribute vs. Edit is the mix-up people hit most often — Edit adds the ability to manage the list or library structure itself, not just its content.

Online vs. on-premises permissions

Feature	SharePoint Online	SharePoint On-Premises
Permission roles	Standardized OOTB roles	More flexibility in role customization
External sharing	Guest access via email/B2B	Requires additional configuration
Group management	Microsoft 365 Groups integration	Traditional SharePoint groups only
Customization	Limited scope for custom roles	More flexibility via PowerShell & UI
Authentication	Cloud-based (Entra ID)	NTLM, Kerberos, on-prem AD

Best practices

Assign to groups, not individuals — the standard advice for a reason: it’s the difference between one membership change and hunting down permissions individually later.
Default to Contribute over Edit for regular content contributors — most people don’t need to restructure lists, just work in them.
Reserve Full Control tightly — it includes the ability to change permissions themselves, which is a different (and higher) trust level than “can edit everything.”
Audit periodically — default roles are easy to over-grant when nobody revisits who actually needs what, six months later.

When would you actually use this?

A project team needs to create and edit documents but shouldn’t be able to change site settings — Contribute or Edit, not Full Control.
Content needs a review step before publishing — Approve permissions on the relevant library, assigned to whoever actually reviews it.
You’re deciding between SharePoint Online and staying on-premises and need to know what actually differs in the permission model, not just marketing language.

References: Microsoft Learn: Permission levels and groups, Microsoft Support: Groups and permissions.

Breaking SharePoint Permission Inheritance — how to actually apply these permission levels at a specific site, library, or item level.
SharePoint Permissions: A Comprehensive Guide — the broader access-control picture beyond just the built-in roles.

That covers the full set of built-in roles. Questions about a specific scenario? Drop them in the comments.