What is a Microsoft 365 permissions model?
Also known as
Definition
Permissions in Microsoft 365 grant users the ability to perform specific actions (view, edit, manage) depending on which workload they're in and how access was granted.
- In SharePoint, permissions flow through three default levels: Read, Edit, and Full Control. Those levels are assigned to users, groups, or Microsoft 365 Groups, and they inherit down through the site (from site to library to folder to file) unless inheritance is broken.
- In Teams, access is managed through roles: Owner, Member, and Guest. These are tied to the underlying Microsoft 365 group. When you add someone to the group, they get access to the connected SharePoint site too.
- Across SharePoint and OneDrive, sharing links add another layer. There are three types: Anyone links (no sign-in required, access can't be audited), Specific people links (recipient must authenticate), and People in your organization links (internal users only, and only those who have the link).
Access can be granted directly to a user, through a group, or through a sharing link. Each method behaves differently during migrations, access reviews, and governance audits.
tip
Microsoft recommends managing access through group or team membership rather than assigning permissions directly to individual users. It's easier to administer, easier to audit, and keeps access consistent across connected resources.
Why it matters
Understanding how permissions work and how they interact across workloads is what separates a clean migration from a messy one, and a governable environment from one that nobody can explain.
- Migration: Permissions don't migrate automatically. Group memberships need to be mapped between source and target. Direct permissions need to be evaluated. Unique permissions from broken inheritance need their own handling. What the permission model looks like at the source determines how much cleanup is needed before anything moves.
- Governance & security: Every permission exception that made sense at the time adds to a model nobody can fully explain later. Direct permissions, broken inheritance, and ungoverned sharing links all compound over time into an access landscape that's difficult to audit and hard to defend.
- AI readiness: Copilot surfaces content based on what users can access. The permissions model determines that. A model with too many exceptions, too much broad access, or too many ungoverned sharing links means Copilot can surface content that was never meant to be found.
Commonly confused with: Conditional access
Conditional access controls whether someone can sign into Microsoft 365 at all based on device, location, or risk level. The permissions model controls what they can do once they're in.
What we see out there
Every exception felt small at the time.
A folder shared with a consultant. A site opened up for a project. A guest given edit access for one document. Over a few years, those accumulate into a permissions model that nobody can fully explain and that IT is left trying to audit before a migration or a Copilot rollout.
Direct permissions are the hardest to clean up.
Group-based access is manageable at scale. Direct permissions assigned to individual users rather than groups aren't. They don't show up in group membership reports, they're easy to miss during access reviews, and they pile up in environments where site owners grant access informally.
Migrations surface what nobody knew was there.
Broken inheritance, unique permissions, and direct assignments that were invisible in day-to-day operations all become visible when content needs to move. The permission model at the source is usually more complex than anyone expected.
Frequently asked questions
What are direct permissions?
Direct permissions are access rights assigned to a specific user rather than a group. They work, but they don't scale. Direct permissions don't show up in group membership reports, making them harder to review and audit. Over time they accumulate, especially in environments where site owners grant access informally and become one of the hardest parts of a permissions cleanup.
What are sharing links?
Sharing links grant access to specific files or folders without modifying the underlying site permissions. There are three types:
1. Anyone links (no sign-in required, access can't be audited)
2. Specific people links (recipients must authenticate)
3. People in your organization links (internal users only).
Anyone links in particular create access that's easy to miss because they don't show up in membership reports and don't expire unless someone sets an expiration date.
What’s inheritance?
By default, everything inside a SharePoint site inherits its permissions from the parent. A library inherits from the site. A folder inherits from the library. A file inherits from the folder. When inheritance is broken to give a folder or file its own permissions, that item starts managing its own access independently. One broken inheritance is fine. Hundreds of them create a permissions model nobody can audit or explain.
Should we preserve all permissions during migration?
Not necessarily. A migration is a good time to simplify. Permissions that exist because of legacy exceptions, one-off requests, or projects that ended years ago don't all need to carry over. Map what's there, understand why it exists, and make an intentional decision about what should land in the target, rather than migrating everything by default and inheriting the same complexity in a new environment.
.avif)