Permission Levels and Groups

SharePoint's permission model is built on two cooperating concepts: permission levels, which are named bundles of individual rights (like the ability to add items, edit items, or manage lists), and SharePoint groups, which are collections of users that you assign a permission level to. Rather than granting rights to people one at a time, an administrator assigns a permission level to a group, and every member of that group inherits those rights on the securable object the group is applied to.

SharePoint ships with several out-of-the-box permission levels. Full Control includes every right, including managing permissions themselves, and is reserved for site owners. Design allows creating lists, editing pages, and applying themes. Edit lets users add, edit, and delete lists and list items but not change site structure. Contribute allows adding and editing items in existing lists without deleting the lists themselves. Read grants view-only access to content, and View Only permits viewing items rendered in the browser (such as via Office Online) without downloading the underlying file. Each level is really a named set of the roughly 33 individual base permissions like ViewListItems, AddListItems, and ManagePermissions.

Every SharePoint site created with the standard template gets three default groups: Site Owners (mapped to Full Control), Site Members (mapped to Edit), and Site Visitors (mapped to Read). Administrators can also create custom SharePoint groups—for example, 'Finance Reviewers' or 'HR Approvers'—and assign any permission level to them, including custom levels built from individual rights. Membership in a SharePoint group can come from individual users, Microsoft 365 groups, or synced Azure AD security groups, giving admins flexibility to manage access at the identity-provider layer while SharePoint groups remain the object being granted rights.

By default, every list, library, folder, and item inherits its permissions from its parent, all the way up to the site. This keeps administration simple: change permissions once at the site level and every subsite, library, and item reflects it. When a specific folder or document needs different access—say, an HR folder that only certain people should see—an admin can 'break inheritance,' which copies the current permissions down to that object as a unique, independent set. From that point forward, changes at the parent no longer propagate to the broken object, and it must be managed separately, which is why Microsoft recommends breaking inheritance sparingly and documenting where it happens.