☕ SharePoint Tip #4 — The SharePoint Permissions Model explained
Good morning! Here is your 15-minute SharePoint tip for today.
Day 4 | Week 1 — Platform Foundations
The SharePoint Permissions Model
Permissions are one of the most critical topics for a SharePoint Product Owner. Getting them wrong causes either security breaches (too open) or frustrated users (too locked down).
The three layers of permissions
SharePoint permissions work in a hierarchy:
1. Site level — controls who can access the entire site
2. Library / List level — can override site permissions for a specific library
3. Item / File level — can override library permissions for a specific file or folder
By default, libraries and files inherit permissions from the site. You only break inheritance when you need exceptions — and exceptions should be rare.
The five built-in permission levels
| Level | What they can do |
|---|---|
| Full Control | Everything — manage permissions, delete the site |
| Design | Edit pages and structure, manage lists |
| Edit | Add, edit, delete items in libraries and lists |
| Contribute | Same as Edit in most configurations |
| Read | View and download only — cannot edit |
SharePoint groups vs Microsoft 365 groups
SharePoint groups are permission containers within a single site. Every site gets three by default: Owners, Members, and Visitors.
Microsoft 365 groups (created when you make a Teams team) grant access to the whole M365 workspace — SharePoint, Teams, Planner, and shared mailbox together.
As a rule: use M365 groups for team-based access, use SharePoint groups for site-specific exceptions.
The golden rules of SharePoint permissions
- Manage permissions through groups, never assign permissions directly to individual users
- Keep inheritance intact as much as possible — broken inheritance is hard to audit
- Use the principle of least privilege — give users the minimum access they need
- Review permissions quarterly — people change roles and leave organisations
Try it today (5 minutes)
Go to any SharePoint site. Click the gear icon (Settings) → Site Permissions. You’ll see the current permission groups and who is in each one. Notice the Owners, Members, and Visitors groups. Click on any group to see the individual members.
As a Product Owner
Permission requests will be one of your most common support topics. The goal is to design a permissions structure that is simple enough that users rarely need to ask for special access. That means getting the group design right upfront — which we’ll cover in depth in Week 2.
See you tomorrow at 6:00 AM with Tip #5 — Lists, Metadata and Content Types!