Sharing & Permissions

Sharing files outside your organisation is one of the easiest things to get wrong. Done well, it’s controlled, traceable, and time-bound. Done badly, it leaks confidential content and creates audit nightmares.

External sharing means giving access to a file or folder to someone outside your organisation — a client, a contractor, a partner, a regulator. SharePoint and OneDrive support this natively, but the way you do it matters a lot. The wrong choice creates risk that lasts years; the right choice is barely more effort and protects everyone involved.

The most common external sharing mistake is also the most preventable: emailing the file as an attachment. Once it’s gone, you’ve lost control of where it ends up, who’s editing what, and which version is current. The right alternative — sharing a link from SharePoint or OneDrive — keeps the file in your environment, lets you change permissions later, and gives you a clear record of who has access.

Modern external sharing in Microsoft 365 supports specific people (recommended), expiry dates, view-only access, download blocking, and password protection. Use them. They’re not enterprise-grade overkill — they’re the basics of professional file handling.

Why this matters

External sharing is where most data breaches actually happen — not through hacking, but through someone forwarding a link to the wrong person, or attaching a file that ends up in a personal inbox.

Email attachments are uncontrollable. Once it leaves your inbox, you have no idea where it goes, who reads it, or how many copies exist.

Persistent links are forgettable. The link you sent a contractor in 2024 is still working in 2026 unless someone removes it. Set expiry dates from day one.

External users behave differently. They forward emails. They share with colleagues. They save copies locally. Plan for that.

When you’ll use this

• When you’re sharing files with a client, contractor, or external partner.
• When you’ve been emailing attachments back and forth and want to stop the version chaos.
• When the content is sensitive and you need a record of who has access.
• When you want time-bound access — for a specific project or review period.

How to do it

1. Make sure the file is stored in SharePoint or OneDrive (not on a desktop or shared drive).
2. Select the file and click Share.
3. Open Link settings — this is where the real control lives.
4. Choose Specific people (the safest option for external sharing).
5. Set permission to View unless they truly need to edit.
6. Add an expiry date if available (most external sharing should be time-bound).
7. Optionally disable Allow download for sensitive content.
8. Enter the external email address(es) and send.
9. When the work is done, return to Manage access and remove the link.

Best practices

• Default to ‘Specific people’ for external sharing. Anyone-with-the-link forwards. Specific people don’t.
• Always set expiry on external links. External access shouldn’t outlive the project.
• Use view-only by default. Edit access is for genuine collaborators, not reviewers.
• Keep external work in a controlled team site. Don’t share from someone’s personal OneDrive — when they leave, the link breaks.
• Audit external access quarterly. Old contractor still has access? Time to clean up.

Common mistakes

• Emailing the file as an attachment. You’ve now lost control. Send a link instead.
• Using ‘Anyone with the link’ for external sharing. Anyone means anyone. The link will end up forwarded, copied, and shared with people you didn’t intend.
• Granting edit access for a one-off review. Reviewers don’t need edit. Use comments instead.
• Not removing access when work is done. Old links live forever. Add a closing step to every external project: revoke access.

↑ Back to top ↑ Back to list

Removing access is just as important as granting it. A clean revoke is a one-minute job. Letting old access linger is how organisations slowly leak data over years.

Every shared file accumulates access permissions over time. People come and go, projects end, contractors move on, but the access often stays — quietly persistent, easily forgotten. The fix isn’t difficult; it’s just usually not done.

There are two ways access happens: direct sharing (you added a person or group) and link-based sharing (you generated a link they can use). Both need to be reviewed and cleaned up. The Manage access panel in SharePoint or OneDrive shows everything in one view, including links you may have forgotten about.

Revoking access doesn’t break anything — the file remains exactly where it is, with the same content. The person who had access just no longer does. Once they try to open the file, they’ll get a ‘request access’ prompt or simply not see it. Done cleanly, the user might not even notice — which is the goal.

Why this matters

Old access is silent risk. A contractor from 2024 can still see your files in 2026 unless you remove them.

Audits notice. Compliance audits flag stale external access faster than almost anything else.

Regular cleanup builds trust. When IT and end users both know files have controlled access, they can collaborate confidently.

When you’ll use this

• When a contractor finishes a project.
• When a colleague moves to a different role or leaves the organisation.
• When you realise a file was overshared and need to lock it down.
• When auditing access during a quarterly cleanup.

How to do it

1. Open the file in SharePoint or OneDrive.
2. Click the file menu (the three dots) and select Manage access.
3. Review who has direct access (people listed by name) and which links exist.
4. For people: click the dropdown next to their name and select Stop sharing.
5. For links: click Stop sharing on the link itself — this disables the entire link.
6. Confirm the change.
7. Test access if needed — try opening the file as that person to verify they’re locked out.

Best practices

• Make revoking part of project closure. Last task on every external project: revoke access.
• Remove the link, not just the people. Links can be forwarded. Disabling the whole link is safer than removing one user.
• Use group-based access for ongoing teams. Easier to remove someone from the group than to remove them from every shared file.
• Audit external access quarterly. 15 minutes a quarter prevents years of accumulated risk.

Common mistakes

• Assuming access was removed when the project ended. Nobody removed it. It’s still there.
• Removing one user from a ‘Anyone with the link’ link. You can’t — the link works for anyone. Disable the link entirely.
• Relying on memory for what was shared with whom. Use Manage access. It shows you the truth.

↑ Back to top ↑ Back to list

You can’t manage what you can’t see. Knowing exactly who has access to a file — and how — is the foundation of safe sharing.

Most people share files without ever checking who already has access. They click Share, add a name, and move on. The result is files that have accumulated dozens of people, multiple links, and inherited group permissions over time — and nobody knows the full picture.

The Manage access panel in SharePoint and OneDrive shows you exactly what’s happening: every person, every group, every active link, with their permission level (view, edit, full control). It’s the single most important tool for sharing hygiene, and it takes 30 seconds to review.

If you find yourself surprised by who has access, that’s the signal to act. Surprise means the access wasn’t deliberate — and unintended access is the most common cause of data exposure.

Why this matters

Unseen access is unmanaged risk. If you don’t know who has it, you can’t control it.

Inherited permissions are invisible. A file might be shared with 50 people via a group you forgot existed.

Links accumulate. Three different links to the same file is normal in messy environments. Manage access surfaces them all.

When you’ll use this

• Before sharing something sensitive, to confirm who already has access.
• When a colleague says ‘I can’t open the file’ — check if they should have access.
• During quarterly access reviews.
• When auditing high-sensitivity libraries.

How to do it

1. Select the file in SharePoint or OneDrive.
2. Click the file menu (three dots) and select Manage access.
3. Review the Direct access list — these are people and groups added by name.
4. Review the Links list — these are sharing links currently active.
5. Note each permission level (view, edit, full control).
6. Identify anything you didn’t expect to see.
7. Take action: remove people, disable links, or tighten permissions as needed.

Best practices

• Check before you share. 30 seconds of review prevents oversharing.
• Look for surprises. Names you don’t recognise, links you don’t remember — these are red flags.
• Use group-based access for teams. One group entry is easier to manage than 30 individual entries.
• Document why exceptions exist. If someone has unusual access, note why so you don’t ‘fix’ something that should stay.

Common mistakes

• Trusting the file name to tell you who can see it. ‘Confidential’ in the name does nothing. The permissions do.
• Sharing without reviewing existing access. You might be granting access to someone who already has it via a group, doubling your audit complexity.
• Ignoring ‘Anyone with the link’ that’s been live for two years. Disable it. Replace with specific people.

↑ Back to top ↑ Back to list

Permissions aren’t permanent. As work changes, so should access. Changing someone from edit to view-only is a 10-second job — and often the right call.

Permissions in SharePoint and OneDrive are designed to be adjusted. Someone moves from being a contributor to a reviewer? Change them to view-only. A file moves from ‘in development’ to ‘final’? Lock down editing. The platform supports all of this without breaking anything; it just needs someone to actually do it.

The three core permission levels are simple: view (read only), edit (can change content), and full control (can change permissions and delete). For 95% of cases, view and edit are all you need. Full control should be limited to file owners and administrators.

Changing permissions doesn’t remove the user — they still have access, just at a different level. They won’t get a notification (unless you choose to send one), so the change is invisible from their perspective until they next try to do something they no longer can.

When you’ll use this

• When someone moves from contributor to reviewer.
• When a file becomes ‘final’ and shouldn’t be edited further.
• When a project transitions from development to production.
• When you want to keep someone informed but stop their direct edits.

How to do it

1. Open the file in SharePoint or OneDrive.
2. Click the file menu and select Manage access.
3. Find the person whose permissions you want to change.
4. Click the dropdown next to their permission level.
5. Select the new level (e.g. change from Can edit to Can view).
6. Confirm the change.
7. Optional: send a brief message explaining the change if it might affect their work.

Best practices

• Use the lowest permission level that still gets the job done. Most people don’t need edit; they need view.
• Lock down ‘final’ files to view-only. Once approved, edits should require explicit re-opening of the file.
• Reserve ‘full control’ for owners and administrators. Most users should never have it.
• Communicate significant changes. If someone loses edit access on a file they use daily, tell them why.

Common mistakes

• Granting edit by default. Most sharing should default to view. Edit is the exception.
• Forgetting that ‘full control’ includes the ability to delete. If you grant it, you’ve granted permission to wipe the file.
• Using complex custom permissions. If your sharing model requires explanation, it’s too complex. Simplify.

↑ Back to top ↑ Back to list

Time-bound access is the single most underused feature in Microsoft 365 sharing. Set an expiry, walk away, and the access cleans itself up.

Most sharing should be temporary. The contractor needs access for a six-week project. The client needs to review a proposal for two weeks. The auditor needs the file for a month. In every case, the right answer is to set an expiry date when you share — so the access ends automatically when the work does.

Expiry dates are part of Link settings in SharePoint and OneDrive. Set one when creating the link, and SharePoint will automatically disable access on that date. No reminders, no manual cleanup, no risk of access lingering beyond its purpose.

Some organisations restrict expiry dates to certain link types or external sharing only. If you don’t see the option, your tenant settings may need adjusting — but for most users, expiry is available and ready to use immediately.

When you’ll use this

• Sharing with external collaborators on a time-bound project.
• Distributing draft documents for review.
• Granting access to vendors, auditors, or one-off reviewers.
• Anytime you’d otherwise feel unsafe leaving the access open indefinitely.

How to do it

1. Select the file and click Share.
2. Open Link settings.
3. Choose Specific people (recommended for sensitive sharing).
4. Set the permission level — usually view-only.
5. Find the Set expiration date option and choose a date.
6. Apply the settings, add recipients, and send.

Best practices

• Set expiry on every external share. Even when you think you’ll need the access long-term — extend later if needed.
• Match the expiry to the project. Six-week project = six-week link. Two-week review = two-week link.
• Combine expiry with view-only and download disabled. Three layers of control instead of one.
• Calendar reminders for reviews are still useful. Check active expiries before they hit, in case extension is needed.

Common mistakes

• Not using expiry because ‘they might need it longer.’ Then extend it. Default-on expiry is much safer than default-on access.
• Setting absurdly long expiries. A two-year expiry isn’t really an expiry. Match it to the actual work.
• Forgetting to extend before it expires. Add a reminder a few days before — extension is one click.

↑ Back to top ↑ Back to list

Most sharing should be view-only. Edit is the exception, not the default. This single habit prevents most accidental damage to shared files.

View-only sharing means the recipient can see the file’s contents but can’t change them. They can read, scroll, view formulas, but they can’t type, delete, or rearrange. This is what most sharing should look like, because most sharing isn’t actually about collaboration — it’s about visibility.

When someone needs to comment on a draft, give feedback, or review for sign-off, they don’t need edit access. View-only with comments enabled covers it. They can highlight text, add comments, and have a conversation without changing the underlying document.

The shift from default-edit to default-view is one of the most powerful sharing habits you can build. It removes the most common source of accidental damage to shared documents — somebody clicking in the wrong place, deleting a paragraph, or ‘fixing’ something that wasn’t broken.

When you’ll use this

• Sharing a finished document for reading or reference.
• Distributing a draft for feedback (use comments instead of edit).
• Sending content to senior stakeholders who don’t need to modify it.
• Sharing externally where edit access would be inappropriate.

How to do it

1. Select the file and click Share.
2. Open Link settings.
3. Choose Specific people or People in your organisation as appropriate.
4. Set permission to Can view.
5. Add recipients and send.
6. If feedback is needed, ask reviewers to use comments rather than edits.

Best practices

• Default to view-only. Edit access is the exception — only grant it when active collaboration is happening.
• Combine view-only with comments enabled for review. Reviewers can have full input without changing content.
• Disable download for highly sensitive content. View-only in the browser, no offline copies.
• Be explicit in the email. ‘Read-only review — please add comments rather than edits’ sets expectations clearly.

Common mistakes

• Granting edit when view would do. Most ‘review’ tasks don’t need edit access. Use comments.
• Assuming view-only blocks downloading. It usually doesn’t — disable download separately if needed.
• Forgetting to remove view access after the work is done. Even view access should be cleaned up when no longer needed.

↑ Back to top ↑ Back to list

When sharing matters, specify who. The ‘Specific people’ link type is the safest, most controlled way to share — and it should be your default for anything sensitive.

There are several types of sharing link in Microsoft 365: ‘Anyone with the link’ (anyone, no sign-in needed), ‘People in your organisation’ (anyone in your tenant), ‘People with existing access’ (no new permissions granted), and ‘Specific people’ (only the named recipients). For most professional sharing, the right answer is ‘Specific people’.

The reason is simple: ‘Specific people’ links don’t work if forwarded. The recipient has to sign in with the email address you sent it to. If they forward the link to a colleague, the colleague gets locked out — exactly the behaviour you want for confidential information.

It’s a small extra step compared to ‘Anyone with the link’, but the protection is significant. It’s the difference between handing someone a marked envelope and posting a flyer on a public noticeboard.

When you’ll use this

• Sharing anything sensitive — HR, financial, legal, strategic.
• Sharing externally with named collaborators.
• When you need an audit trail of who accessed what.
• Anytime you’d object to the file being forwarded.

How to do it

1. Select the file and click Share.
2. Open Link settings.
3. Choose Specific people.
4. Add each recipient by email address.
5. Set the permission level (usually view).
6. Add an expiry date if appropriate.
7. Send the link.

Best practices

• Default to ‘Specific people’ for sensitive content. It’s the most controlled option.
• Add recipients individually rather than to a group. Group sharing makes sense for team work, not sensitive distribution.
• Combine with expiry and view-only. Layered controls > single controls.
• Re-share rather than forward. If a colleague needs the file too, share it with them properly — don’t forward the original link.

Common mistakes

• Defaulting to ‘Anyone with the link’ for convenience. Convenience now is risk later.
• Sharing with a wide email distribution list. Specific people means specific people — pick them deliberately.
• Forgetting that ‘Specific people’ links can’t be forwarded. If the recipient forwards it, you’ll get an access request from someone unexpected. That’s the system working correctly.

↑ Back to top ↑ Back to list

View-only with download disabled is the highest practical control level for sensitive sharing. The recipient can read but not save, copy, or take it offline.

When you share a file in view-only mode, by default the recipient can still download a copy. That copy escapes your control — they can save it, forward it, edit it locally, send it onward. For genuinely sensitive content, this is the loophole you want to close.

Disabling download keeps the file in the browser. The recipient can read, scroll, see the content, but they can’t save a local copy. They can’t print it (in many cases) and they can’t take screenshots without significant effort. It’s not absolute security — nothing on a screen ever is — but it’s a meaningful step up from default sharing.

This setting is found in Link settings, alongside expiry and password protection. It’s tenant-dependent, so if you don’t see it, your organisation may have it disabled. For sensitive financial, HR, or legal content, ask your IT team to enable it.

When you’ll use this

• Sharing draft proposals or strategic documents externally.
• Distributing reports that shouldn’t end up on local hard drives.
• Sharing financial or HR data with reviewers.
• Anytime you’d object to the file existing on someone’s laptop.

How to do it

1. Select the file and click Share.
2. Open Link settings.
3. Choose Specific people for tightest control.
4. Set permission to Can view.
5. Find the Allow download toggle (or ‘Block download’) and disable it.
6. Send the link.
7. Confirm with the recipient that they can read but not download — useful to verify the setting worked.

Best practices

• Combine with view-only access. Edit + no download is contradictory.
• Use for any sensitive external sharing. If they don’t need a local copy, don’t give them one.
• Pair with expiry dates. Time-bound + browser-only = strong basic control.
• Communicate the constraint. Tell recipients up-front it’s view-only with no download — saves the support email later.

Common mistakes

• Treating download blocking as absolute security. It’s a meaningful control, not a guarantee. Plan accordingly.
• Granting download to people who only need to read. Default to disabled, enable only when needed.
• Forgetting to enable it for sensitive content. If you’re sharing financials externally, this should always be on.

↑ Back to top ↑ Back to list

Adding a password to a sharing link is the simplest way to ensure that even if the link gets forwarded, the file stays protected.

Password-protected sharing links require recipients to enter a password before accessing the file. Even if the link is forwarded, copied, or shared accidentally, the file remains locked unless the password is also shared — which it shouldn’t be over the same channel.

It’s not a replacement for proper permissions, but it adds a useful layer when sharing externally with people who don’t have a corporate identity to authenticate against. Combined with expiry and view-only, it gives you a robust set of controls for time-bound external access.

The trick is communicating the password securely. Send the link in email, send the password through Teams, SMS, or a phone call. Never put both in the same message — that defeats the purpose entirely.

When you’ll use this

• Sharing externally with people who don’t have a Microsoft account.
• Distributing time-bound, sensitive content to a defined audience.
• When the recipient is unknown to your organisation but the content needs protection.
• When you want to ensure the link can’t be casually forwarded.

How to do it

1. Select the file and click Share.
2. Open Link settings.
3. Find the Set password option (if available in your tenant).
4. Enter a strong password.
5. Save the password securely — you’ll need to share it separately.
6. Send the link to the recipient.
7. Send the password via a different channel (text, phone call, Teams).

Best practices

• Never send the password in the same channel as the link. Email link, text password. Or vice versa.
• Use strong passwords, not ‘Welcome1’. If it’s worth protecting, it’s worth protecting properly.
• Don’t reuse passwords across files. One compromised password should affect one file, not your entire portfolio.
• Combine with expiry. Password + expiry + view-only is a strong baseline for external sharing.

Common mistakes

• Sending the password in the same email as the link. Defeats the entire point.
• Using weak or shared passwords. Treat each share as a unique key.
• Relying on passwords as your only control. Layer with permissions, expiry, and download blocking.

↑ Back to top ↑ Back to list

Sometimes you need one stable link to a file that you can share repeatedly, embed in pages, or reference across multiple communications. Reusable links solve this — when used carefully.

A reusable sharing link is one that doesn’t expire and works for everyone who’s been granted access. It’s useful when a file is referenced from many places — embedded in a SharePoint page, linked from a team wiki, referenced in onboarding materials — and you don’t want to manage dozens of separate sharing actions.

The trade-off is control. A reusable link that gets forwarded is now in the wild, and you may not know where. The mitigation is to scope the link tightly: people in your organisation only, view-only access, no edit. That way even if it spreads, it spreads only within your tenant and only as read access.

Reusable links should be reviewed periodically. The ‘Manage access’ panel shows every link in existence on a file. Stale links should be disabled, especially if they grant broader access than is currently needed.

When you’ll use this

• Embedding a file in a SharePoint page or intranet article.
• Referencing a frequently-used template in onboarding documentation.
• Linking from multiple Teams channels to the same shared resource.
• Anywhere you need a stable URL that won’t break.

How to do it

1. Select the file and click Share.
2. Open Link settings.
3. Choose People in your organisation (most common for reusable internal links).
4. Set permission to Can view.
5. Click Apply and copy the link.
6. Use the link wherever you need it — pages, emails, channels.
7. Periodically review the link in Manage access to confirm it’s still appropriate.

Best practices

• Use ‘People in your organisation’ rather than ‘Anyone’. Even reusable links should be scoped tightly.
• Default to view-only. Reusable + edit = recipe for accidents.
• Embed once, reference many times. Don’t generate separate links for each use; reuse the same one.
• Review reusable links quarterly. They tend to outlive their usefulness if no one checks.

Common mistakes

• Using ‘Anyone with the link’ for reusable internal references. Way too permissive. Use organisation-scoped links instead.
• Granting edit on a widely-distributed link. Now anyone who finds the link can change the file.
• Letting reusable links accumulate. Every active link is an active risk. Clean them up regularly.

↑ Back to top ↑ Back to list

Folder-level sharing makes onboarding new team members easy — but used carelessly, it creates permission spaghetti that’s almost impossible to clean up.

Sharing a folder grants access to everything inside it: existing files, future files, and subfolders. For active team work this is convenient — add someone to the folder and they immediately have access to the whole project — but it’s also where SharePoint permissions models often start to break down.

The cleanest approach is to share folders only inside team sites where the team’s permissions are already defined. Members of the team get folder access automatically; you only need to share specifically when granting external or cross-team access. This keeps the model simple and predictable.

When you do share a folder externally or across teams, treat it the same way as sharing a file: specific people, view-only by default, with expiry where possible. The fact that it’s a folder doesn’t change the principles — it just multiplies the impact of getting them wrong.

When you’ll use this

• Onboarding a new team member who needs access to all the team’s files.
• Sharing a project folder with an external contractor.
• Granting cross-team access to a resource library.
• Migrating from email-attachment chaos to centralised collaboration.

How to do it

1. Navigate to the folder in SharePoint or OneDrive.
2. Select the folder (don’t open it) and click Share.
3. Open Link settings.
4. Choose Specific people for external access, or the team’s group for internal access.
5. Set permission level — view by default.
6. Add expiry if appropriate.
7. Send the link.

Best practices

• Prefer team-level permissions over folder-level sharing inside team sites. Cleaner, simpler, easier to audit.
• Use group-based sharing when possible. Adding a person to a group is easier than re-sharing every folder.
• Default to view-only for folder sharing. Edit access on a whole folder is a lot of trust.
• Audit folder access quarterly. External folder shares should be the first to go when projects close.

Common mistakes

• Sharing a folder with ‘Anyone with the link’. The blast radius is huge — every file, every subfolder, all viewable.
• Granting edit on a folder externally. Now anyone with the link can add, change, or delete files. Don’t.
• Sharing one folder with three different links over time. Permission spaghetti. Use one canonical access method.

↑ Back to top ↑ Back to list

Some files are genuinely meant for everyone in the organisation — policies, handbooks, all-staff announcements. Sharing them broadly is the right call. The trick is doing it deliberately.

‘Share with everyone’ typically means sharing with everyone in your Microsoft 365 tenant — your whole organisation — not the entire internet. This is the right approach for content that’s genuinely organisation-wide: HR policies, the staff handbook, the IT support guide, the latest all-hands deck.

The mechanism is the ‘People in your organisation’ link type. Anyone in your tenant who has the link can access the file (within whatever permissions you’ve granted). It’s not externally exposed, but it is broadly available — which means it should be content you’d be comfortable seeing on a noticeboard in the canteen.

Don’t confuse this with ‘Anyone with the link’, which means anyone on the internet, including people outside your organisation. Those two link types look similar in the UI but have completely different security implications.

When you’ll use this

• Publishing organisation-wide policies, handbooks, or guides.
• Sharing all-hands meeting recordings or decks.
• Distributing newsletters or announcements that everyone should see.
• Building intranet pages that link to broadly-available resources.

How to do it

1. Make sure the content is genuinely appropriate for everyone — no PII, no confidential information.
2. Store the file in an appropriate location (often the corporate intranet site).
3. Click Share.
4. Open Link settings.
5. Choose People in your organisation.
6. Set permission to Can view.
7. Copy the link and share it via your normal communication channels.

Best practices

• Use view-only for organisation-wide content. Edit access at this scale is asking for trouble.
• Store organisation-wide content in dedicated sites. An ‘Everyone’ or ‘Intranet’ site keeps these files separate from team work.
• Review broadly-shared content periodically. Old policies become misinformation if not actively maintained.
• Be deliberate. ‘People in your organisation’ is the correct setting — but don’t pick it by accident.

Common mistakes

• Confusing ‘Everyone’ with ‘Anyone’. Everyone is internal. Anyone is the whole internet. Pick carefully.
• Sharing confidential content broadly because ‘everyone needs to see it’. Most of the time, ‘everyone’ means the team, not the organisation.
• Granting edit access organisation-wide. Some employee, somewhere, will accidentally delete the entire document.

↑ Back to top ↑ Back to list

Anonymous sharing — ‘Anyone with the link’ — has its uses, but it’s the riskiest sharing option in SharePoint. Use it deliberately, sparingly, and never for sensitive content.

An anonymous sharing link works for anyone on the internet who has the URL. No sign-in, no authentication, no identity. It’s effectively the digital equivalent of pinning a document to a public noticeboard — which is sometimes exactly what you want, but more often not.

The legitimate uses are rare but real: distributing public marketing materials, sharing event registration forms, providing public-facing reference documents. For everything else — internal documents, sensitive content, anything that requires accountability — use ‘Specific people’ or organisation-scoped links instead.

Many organisations restrict or disable anonymous sharing entirely at the tenant level. If you find you can’t create one, that’s almost always intentional. Talk to IT before assuming it’s a problem to solve.

When you’ll use this

• Public marketing content (press releases, public reports, brochures).
• Event registration or public-facing forms.
• Reference materials genuinely intended for the public.
• Almost nothing else.

How to do it

1. Confirm the content is appropriate for fully public access.
2. Click Share.
3. Open Link settings.
4. Choose Anyone with the link (if your tenant allows it).
5. Set permission to Can view — never edit.
6. Set an expiry date (if available).
7. Copy the link and use it.

Best practices

• View-only, always. Anonymous edit access is almost never appropriate.
• Set expiry dates aggressively. Public links should be time-bound where possible.
• Disable download for sensitive-but-public content. The browser-only constraint reduces casual redistribution.
• Default to other link types. Anonymous should be the exception, not the default.

Common mistakes

• Using ‘Anyone with the link’ because it’s the easiest option. Easy now, regret later.
• Granting edit access anonymously. Now anyone in the world can change your file. Don’t.
• Forgetting to revoke anonymous links. They live forever unless someone disables them. Add expiry, then audit.

↑ Back to top ↑ Back to list

Sharing is easy. Tracking what you’ve shared is harder — and matters more. The ‘Shared by me’ view in OneDrive is the answer.

OneDrive maintains a list of every file and folder you’ve personally shared, accessible from the ‘Shared by me’ view. It’s the single best place to audit your own sharing, identify stale links, and clean up access that’s no longer needed.

Most people share files dozens of times a year and never review what they’ve created. The result is a long tail of forgotten links — to ex-colleagues, completed projects, old contractors, and discontinued initiatives. Each one is a potential exposure point.

Reviewing ‘Shared by me’ takes 15 minutes a quarter and is one of the most valuable habits you can build. It’s also genuinely satisfying — you’ll be amazed how much accumulated sharing you’d forgotten about.

When you’ll use this

• Quarterly access reviews — yours or your team’s.
• When changing roles or leaving an organisation.
• When auditing personal sharing hygiene.
• When a security event prompts review of past sharing.

How to do it

1. Open OneDrive in the browser.
2. In the left navigation, click Shared.
3. Switch to the Shared by you view.
4. Review each item — what was shared, with whom, when.
5. For anything that’s no longer needed, click the file and select Manage access.
6. Remove old links and individuals.
7. Repeat quarterly.

Best practices

• Set a recurring 15-minute calendar block for sharing review. Once a quarter is enough.
• Start with the oldest shares. The risk increases with age — old links are forgotten links.
• Remove links rather than individual people. Disabling the link is more thorough than removing one user from it.
• Don’t keep shares ‘just in case’. If they need access again, share again. Don’t leave permissions hanging.

Common mistakes

• Never reviewing your shared files. Every active share is an active risk. Audit them.
• Trusting your memory. You’ll be surprised how much you’ve shared and forgotten.
• Ignoring shares from team sites. ‘Shared by me’ covers personal sharing — team site sharing should be reviewed at the site level.

↑ Back to top ↑ Back to list

The other side of sharing: knowing what others have shared with you. The ‘Shared with me’ view consolidates everything you’ve been granted access to.

Just as OneDrive tracks files you’ve shared, it also tracks files shared with you. The ‘Shared with me’ view is the master list of every file and folder where someone else has explicitly granted you access — across the entire organisation.

This is invaluable for finding things. A colleague sent you a link three weeks ago, you can’t remember the exact filename, but you know it’s there somewhere. ‘Shared with me’ surfaces it, sorted by date, with the sharer visible. Beats searching through old emails.

It’s also useful for understanding your access footprint. Files shared with you are still in your name in audit logs — if you have access you didn’t expect, that’s worth investigating. Maybe a colleague meant to share it with someone else; maybe it’s a permissions error worth flagging.

When you’ll use this

• Looking for a file someone shared with you recently.
• Tracking what you have access to across teams and projects.
• Identifying access you no longer need (ask the owner to remove it).
• Onboarding into a new role and reviewing what’s been shared.

How to do it

1. Open OneDrive in the browser.
2. In the left navigation, click Shared.
3. Switch to the Shared with you view.
4. Sort by date or name to find what you need.
5. Click any item to open it directly.
6. If you no longer need access, ask the file owner to remove you (you can’t revoke your own access in most cases).

Best practices

• Use ‘Shared with me’ as your default ‘where’s that file’ tool. Faster than searching email.
• Bookmark or favourite frequently-used shared files. Don’t re-search every time.
• Flag unexpected access. If you have access to something you shouldn’t, tell the owner.
• Don’t rely on ‘Shared with me’ for permanent access. If you need ongoing access, the file should be in a team site you’re part of, not just shared individually.

Common mistakes

• Treating ‘Shared with me’ as a comprehensive file inventory. It only includes explicit shares — files in team sites won’t appear here.
• Ignoring it. Most users never look at this view. It’s one of the most useful things in OneDrive.
• Bookmarking links without remembering the source. If the file moves or access is revoked, the bookmark breaks.

↑ Back to top ↑ Back to list

Cleaning up an over-shared environment is one of the highest-impact things a team can do. It’s also one of the most tedious. Start with the broadest links.

Many SharePoint environments accumulate over-sharing over time: ‘Anyone with the link’ on files that should be specific-people, organisation-wide access on team-only documents, edit permissions where view would suffice. The fix is not glamorous — it’s just methodical review.

Start with the broadest links first. ‘Anyone with the link’ files are the highest-risk and easiest to identify. Convert them to ‘Specific people’ or ‘Organisation’ depending on the actual need. Most files that have anonymous links don’t need them.

Then work down: organisation-wide files that should be team-only, team files with broader access than necessary, individual edit permissions that should be view. The full cleanup might take weeks for a complex environment, but every link tightened is a risk reduced.

When you’ll use this

• Periodic security or compliance reviews.
• After a sharing-related incident or near-miss.
• When migrating to a more controlled environment.
• When onboarding new team members reveals legacy chaos.

How to do it

1. Identify the files most at risk — usually those shared with ‘Anyone with the link’.
2. Open Manage access on each file.
3. Disable broad links and replace with appropriately-scoped ones.
4. Remove individuals who no longer need access.
5. Adjust permission levels (edit → view where appropriate).
6. Document any exceptions — files that genuinely need broad access.
7. Schedule recurring reviews.

Best practices

• Start broad, work narrow. Anonymous links first, then organisation, then team, then individual.
• Use admin reports if available. SharePoint admins can pull reports of all ‘Anyone’ links across a tenant — far faster than manual review.
• Communicate before removing. If you revoke access someone is actively using, tell them first.
• Treat cleanup as ongoing, not one-off. Sharing accumulates again. Make review a recurring habit.

Common mistakes

• Trying to fix everything at once. Pick a manageable scope (one site, one library) and do it properly.
• Removing access without warning. Disrupts work, generates support tickets, breaks trust.
• Stopping after the first cleanup. Sharing chaos returns. Schedule recurring reviews.

↑ Back to top ↑ Back to list

Sharing a file in Teams chat looks simple, but it has consequences most people don’t realise. Where the file actually lives — and who can see it long-term — depends on choices you make in the moment.

When you upload a file directly into a Teams chat, it’s stored in your personal OneDrive — not the team’s SharePoint site. Microsoft handles the sharing automatically, granting access to the people in the chat. It works, but it has hidden implications: when you leave the organisation, that file may become inaccessible. It’s not part of the team’s record. It’s tied to you, not the work.

The better pattern, for any file that matters beyond the immediate conversation, is to upload it to the team’s SharePoint site (often via a Teams channel’s Files tab) and then share the link in chat. The file lives in team-owned storage, the chat references it, and the conversation context is preserved without locking the file to a single person.

For genuinely throwaway files — a screenshot, a PDF you’re forwarding for one comment — direct chat upload is fine. For anything you’d want to find again in six months, do it the long way and put the file in a team-owned location first.

When you’ll use this

• Quick, throwaway file sharing in a one-off chat.
• Forwarding a file someone sent you that another colleague asked about.
• Screenshots, casual references, in-the-moment exchanges.
• When you genuinely don’t need the file to outlive the chat.

How to do it

1. Open the Teams chat.
2. Click the paperclip (Attach) icon.
3. Choose Upload from this device for a one-off, or OneDrive / Recent files to share an existing file as a link.
4. Add any context in the chat message.
5. Send.
6. If the file matters longer-term, move it to a team site afterwards.

Best practices

• For team-relevant files, use channels not chats. Channel files live in the team’s SharePoint site — accessible to everyone, not tied to one person.
• Share existing files as links, not uploads. Better than creating a duplicate copy in OneDrive.
• Move important chat files to team storage afterwards. Don’t leave them stranded in personal OneDrive.
• Be aware of who can access. Files shared in chat are accessible to everyone in that chat — including future participants.

Common mistakes

• Treating chat as durable file storage. Chat files end up in personal OneDrive — they’re not part of the team’s permanent record.
• Uploading the same file to multiple chats. Three chats, three copies. Use a shared link instead.
• Sharing sensitive files in large group chats. Everyone in the chat — and anyone added later — has access.

↑ Back to top ↑ Back to list

Files shared in a channel live in the team’s SharePoint site, automatically accessible to all team members. It’s the cleanest place to share team work — and the foundation of healthy team collaboration.

Every Teams channel has a Files tab. That tab is a window into a folder in the team’s underlying SharePoint site. When you upload a file via the Files tab, you’re putting it in shared team storage — not your personal OneDrive — with the team’s permissions automatically applied.

This is the right default for any file that’s part of team work. Project documents, meeting notes, drafts, references — anything that should be available to the whole team should live in the channel’s Files tab, not in chat or in someone’s personal storage.

The advantage is permanence and discoverability. Team members can find files via the Files tab, search across the team, and continue accessing them when individuals come and go. It’s the difference between team-owned work and personally-owned work.

When you’ll use this

• Sharing project files, drafts, or documents within a team.
• Distributing meeting notes and outcomes.
• Building shared references that the whole team should access.
• Any file work that’s bigger than a single chat conversation.

How to do it

1. Open the relevant Team and channel.
2. Click the Files tab.
3. Upload the file (drag-and-drop or use the Upload button).
4. Optionally create folders to organise content.
5. When mentioning the file in chat, link to it from the Files tab — don’t re-upload.

Best practices

• Default team file sharing to channels, not chats. Channel files live in shared team storage; chat files don’t.
• Use folders sparingly. Heavy folder structures don’t scale; metadata and views handle organisation better.
• Link to channel files from chat, don’t re-upload. Avoid duplicates, maintain one source of truth.
• Treat the channel as the team’s filing cabinet. If it matters to the team, it goes here.

Common mistakes

• Sharing important team files in chat instead of channel Files. Wrong storage, wrong long-term ownership.
• Creating elaborate folder hierarchies in channel Files. SharePoint metadata works better. Don’t recreate the file server in your team site.
• Treating the channel Files tab as a dumping ground. Like any shared folder, it needs care and curation.

↑ Back to top ↑ Back to list

Email + attachment is the version-control disaster the entire industry is still recovering from. Email + link to a SharePoint file is the cure — and it costs nothing extra.

Outlook can attach files in two ways: as a copy (the traditional attachment) or as a link to a file in OneDrive or SharePoint. The second option is dramatically better for almost every situation. The recipient sees the latest version, you keep version control, edit history is preserved, and nobody ends up working on stale copies.

When you click ‘Attach’ in Outlook, it now defaults to suggesting your recent OneDrive and SharePoint files. If you pick one from there, it goes as a link, with permissions adjusted automatically. Two clicks, total. The result is a far healthier collaboration pattern than ‘find the latest version’ email threads.

For external sharing the same principle applies, just with extra care around link permissions. Default to ‘Specific people’ for external email links, view-only for reviewers, and add expiry where the conversation will be time-bound.

When you’ll use this

• Almost every time you’d previously attach a file to an email.
• Sharing drafts for review.
• Distributing reports, proposals, or completed work.
• External communication where you’d benefit from access control and expiry.

How to do it

1. Compose your email in Outlook.
2. Click Attach file.
3. Pick a file from Recent (OneDrive/SharePoint) — Outlook will attach as a link.
4. If sharing externally, click the link in the email and adjust permissions (Specific people, view-only, expiry).
5. For internal recipients, the default is usually fine — they’ll get appropriate access automatically.
6. Send.

Best practices

• Stop sending traditional attachments. Default to links. The version-control benefits compound.
• Adjust link permissions for sensitive content. External email = Specific people, view-only.
• Use the file’s existing location. If it’s already in SharePoint, link there — don’t upload to OneDrive first.
• Educate your team. One person sending links isn’t enough; the whole team needs to adopt the habit.

Common mistakes

• Attaching files when a link would do. Every attachment is a version-control problem in waiting.
• Sending links with overly broad permissions. Adjust before sending — don’t trust defaults for sensitive content.
• Saving a copy ‘just in case’. If you trust the link, you don’t need a backup copy. Saving copies defeats the entire purpose.

↑ Back to top ↑ Back to list

Email attachment limits are still a thing — typically 25-50 MB. SharePoint and OneDrive don’t care; they handle files up to 250 GB. For anything large, sharing via link is the only sensible option.

Most email systems cap attachments at somewhere between 25 MB and 50 MB. Try to send a video, a complex PDF, or a presentation with embedded video, and the email bounces. The traditional workaround was to compress, split, or use third-party services — all clumsy, all unnecessary in a Microsoft 365 environment.

The right approach: upload the file to SharePoint or OneDrive and share a link. There’s no practical size limit (up to 250 GB per file in current Microsoft 365 environments), no recipient inbox impact, and the recipient downloads from a stable URL rather than a fragile email attachment. It’s faster and more reliable.

For genuinely large files (videos, datasets, archives), this becomes essential. But the same approach works just as well for medium files where the 25 MB cap is the only blocker. Build the habit for everything; it scales naturally.

When you’ll use this

• Sharing videos, presentations with embedded media, or large datasets.
• Anytime an email attachment fails or is bounced.
• Distributing zip archives or technical files to colleagues.
• Sending files to external partners who’d otherwise need a third-party tool.

How to do it

1. Upload the file to OneDrive or the relevant SharePoint location.
2. Wait for upload to complete (large files can take a few minutes).
3. Click Share on the file.
4. Open Link settings and choose appropriate permissions.
5. Set expiry and view-only as appropriate.
6. Copy the link.
7. Paste into email or chat with context.

Best practices

• Don’t attempt to email large files. Use a link. Always.
• For videos, consider Microsoft Stream. Better for streaming than raw file downloads.
• Compress folders, but only when sharing as a unit. A zip of 50 individual files becomes one downloadable item.
• Set expiry on large external shares. Large files = larger risk if the link leaks.

Common mistakes

• Splitting files to fit email size limits. Worse than the original problem. Use a link.
• Using third-party file transfer services when SharePoint will do. Adds a tool, splits your environment, creates governance gaps.
• Forgetting to test the link. For very large files, verify the recipient can actually download it before assuming they can.

↑ Back to top ↑ Back to list

Most external access should be temporary. Combining ‘Specific people’, view-only, and an expiry date is the gold standard for time-bound sharing.

Temporary access isn’t a separate feature in SharePoint — it’s a combination of existing controls used together. ‘Specific people’ restricts who can use the link. View-only restricts what they can do. The expiry date ensures access ends automatically when the work is done.

Used together, these three controls produce something genuinely useful: time-bound, low-impact, low-risk access for collaborators who need to participate temporarily. A six-week contractor, an external auditor, a guest reviewer — all the same pattern, all clean up after themselves.

The only thing the platform won’t do automatically is review whether you’ve extended access beyond what was originally intended. Build a habit of reviewing active expiries before they hit, and extending only when there’s a real need.

When you’ll use this

• External contractors on time-bound projects.
• Audits, reviews, or one-off external collaborations.
• Granting temporary access during transitions or handovers.
• Anytime you’d otherwise feel uneasy about access lingering indefinitely.

How to do it

1. Select the file and click Share.
2. Open Link settings.
3. Choose Specific people.
4. Set permission to Can view.
5. Set an expiry date matching the project length.
6. Disable download for sensitive content.
7. Send the link.
8. Add a calendar reminder to review before expiry.

Best practices

• Combine three controls: specific people, view-only, expiry. Each strengthens the others.
• Match expiry to actual work duration. Not ‘forever, just in case’ — match it to reality.
• Review active shares before expiry. Extend if needed; let expire if not.
• Document temporary shares for sensitive content. Audit trail matters when external access is involved.

Common mistakes

• Treating temporary as permanent. A two-year link isn’t temporary; it’s permanent with a token gesture.
• Forgetting to extend before expiry. Don’t let working access lapse just because the calendar said so.
• Granting edit access for read-only review. Reviewers don’t need edit. Use comments.

↑ Back to top ↑ Back to list

Group-based sharing is the foundation of scalable permissions. Add someone to the group, they get access to everything the group can see. Remove them, access vanishes everywhere at once.

Microsoft 365 has multiple kinds of groups: distribution lists, security groups, Microsoft 365 groups (the default behind Teams), and SharePoint groups within sites. They serve overlapping purposes, but for sharing, the principle is the same: grant access to a group, manage membership of that group, and access automatically follows membership.

This is far more scalable than granting individual access. If a team has 30 members and 50 shared files, individual permissions mean 1,500 entries to manage. Group-based permissions mean 50 entries (one per file, granted to the group). Adding a new team member updates all 50 files at once.

For most team sharing, the right approach is to create the file inside a team site (which already has its own group) and let permissions flow from there. For cross-team sharing or specific needs, share with the relevant group rather than naming individuals one by one.

When you’ll use this

• Sharing within a team or department where membership changes regularly.
• Cross-team sharing where you want consistency without manually updating individual access.
• Granting access to roles rather than people (e.g. ‘Project Managers’).
• Anywhere individual sharing would create maintenance burden.

How to do it

1. Identify the right group — Microsoft 365 group, security group, or SharePoint group.
2. Select the file and click Share.
3. Type the group name in the recipients field.
4. Set the permission level for the group as a whole.
5. Confirm and send.
6. When team membership changes, the access updates automatically.

Best practices

• Default to groups for team-wide sharing. Individuals only when there’s a real reason to.
• Use existing groups before creating new ones. Group sprawl is its own problem; reuse where possible.
• Document what each group is for. ‘Marketing team’ is clear. ‘Group_2024_Project_X’ six months later is not.
• Audit group membership. Same principle as auditing file access — but at the group level.

Common mistakes

• Granting individual access when a group would do. Creates maintenance debt that compounds over time.
• Using one big ‘Everyone’ group for everything. Too broad to be useful. Match groups to actual access needs.
• Forgetting to remove people from groups when their roles change. Groups are only as good as their membership.

↑ Back to top ↑ Back to list

Auditing isn’t just for compliance — it’s how you spot the slow, silent accumulation of access that nobody intended. Done regularly, it’s quick. Done never, it’s a disaster waiting to happen.

An access audit is a deliberate review of who can see, edit, or control a file or library. It’s not the same as casually checking ‘Manage access’ once — it’s a structured review with specific questions: who has access, why do they have it, is it still appropriate, what’s the risk if it’s wrong?

For high-risk content (HR files, financial reports, strategic plans, anything regulated), audits should be regular and documented. For everyday team work, a lighter quarterly review is enough. For most personal OneDrive content, an annual sweep handles it.

The tools are mostly already there: Manage access on individual files, sharing reports for tenant-wide visibility (admin-only), and the ‘Shared by me’ view in OneDrive for personal sharing. What’s needed is the discipline to actually use them.

When you’ll use this

• Regular reviews of high-sensitivity content (HR, finance, legal).
• Quarterly cleanup of personal sharing.
• After security incidents or near-misses.
• When migrating, restructuring, or transitioning content ownership.

How to do it

1. Identify what you’re auditing — single file, library, site, or your personal sharing.
2. Open Manage access on the relevant items.
3. List every person, group, and link.
4. For each: confirm purpose, current need, and appropriate permission level.
5. Remove anything no longer needed.
6. Adjust permission levels where current grants are too broad.
7. Document the audit (date, what changed, who reviewed).
8. Schedule the next audit.

Best practices

• Audit on a schedule, not just when there’s a problem. Regular small audits beat occasional big ones.
• Document the audit. ‘Reviewed and confirmed appropriate’ is a useful audit trail.
• Focus on broad access first. Anonymous links and organisation-wide shares carry more risk than individual permissions.
• Involve content owners. The person who created the content knows whether access is still appropriate.

Common mistakes

• Auditing only after something goes wrong. By then, the damage is done.
• Treating audit as a one-off. Sharing accumulates again. Schedule recurring reviews.
• Auditing without authority to change. If you find a problem but can’t fix it, the audit produced anxiety, not improvement.

↑ Back to top ↑ Back to list

Sometimes you need to share a document but protect specific sections — pricing in a proposal, formulas in a template, signatures in a form. SharePoint can’t do this alone, but Word and Excel can.

Permission models work at the file level: someone has access or they don’t, can edit or can’t. Within a single file, you can share with edit access but still want to protect specific sections — a header, a formula, a signature block, a table of fixed prices. This is where Word and Excel’s built-in protection features come in.

In Word, you can mark sections as restricted while leaving others open. In Excel, you can protect specific cells, formulas, or sheets while permitting edits elsewhere. These are document-level controls, separate from SharePoint permissions, but they layer cleanly on top.

The protection isn’t unbreakable — a determined user with full access could remove it — but it prevents accidental damage and signals intent clearly. For most collaboration, that’s enough.

When you’ll use this

• Templates where users should fill in fields but not change structure.
• Forms with protected sections (signatures, calculations).
• Documents with mixed sensitivity (some sections collaborative, others fixed).
• Spreadsheets with formulas users shouldn’t accidentally overwrite.

How to do it

1. In Word: Use Review > Restrict Editing to limit changes to specific sections.
2. In Excel: Use Review > Protect Sheet (with optional password) to lock specific cells while permitting edits in others.
3. Choose what users can and can’t do.
4. Save the file with protection enabled.
5. Share via SharePoint as normal — the document-level protection persists.
6. Test as a different user to confirm the protection works as intended.

Best practices

• Use document-level protection sparingly. Most files don’t need it; over-use creates friction.
• Combine with SharePoint permissions. Layered controls are more effective than single ones.
• Document protections and passwords. If you set a password, store it somewhere others can find when needed.
• Consider templates and content controls. For repeatable forms, content controls in Word are cleaner than restriction.

Common mistakes

• Relying on document protection for security. It’s about preventing accidents, not preventing determined users.
• Setting passwords nobody else knows. When the original owner leaves, the file becomes unmaintainable.
• Over-protecting collaborative documents. If users can’t easily contribute, they’ll find workarounds — usually worse than the original.

↑ Back to top ↑ Back to list

Sometimes you need access to a file you don’t have. The ‘Request access’ workflow turns a frustrating dead-end into a clean path to permission.

When you click a link to a SharePoint or OneDrive file you don’t have access to, you’ll see one of two things: an outright ‘Access denied’ message, or a ‘Request access’ option. The second is far more useful — you can send a structured request to the file owner explaining who you are and why you need access.

Owners receive these requests by email and can grant or deny access in one click. It’s a much cleaner workflow than the alternative — emailing the owner, explaining the situation, waiting for them to share manually, hoping they get the permissions right. Request access lets the platform handle the mechanics.

The user experience matters: include context in the request. ‘I need access for the Q3 review’ is much more actionable than a generic request. Owners are more likely to approve quickly when they understand the why.

When you’ll use this

• When you click a SharePoint or OneDrive link and find you don’t have access.
• When you’ve been told a file exists but the link doesn’t work for you.
• When you join a project mid-flight and need access to existing materials.
• When permissions need updating to reflect a change in role.

How to do it

1. Click the link to the file you can’t access.
2. On the access denied screen, click Request access.
3. Add a brief message explaining who you are, what you’re working on, and why you need access.
4. Submit the request.
5. The file owner receives an email and can approve or deny.
6. If urgent, also message the owner directly with the link to your request.

Best practices

• Include context in the request. ‘I’m joining the project team and need access to ongoing files’ is far more useful than ‘please share’.
• Request the right permission level. ‘View access for review’ is more likely to be granted quickly than ‘edit access’.
• Don’t email people for files when ‘Request access’ exists. Use the platform — it creates a clean audit trail.
• Follow up if urgent. Owners might not see the email immediately. A direct message helps.

Common mistakes

• Asking IT to bypass permissions. IT shouldn’t grant access without the owner’s approval — request through the proper channel.
• Submitting requests without context. Owners get many requests; vague ones are deprioritised.
• Re-requesting repeatedly. If the request hasn’t been granted, message the owner directly rather than spamming requests.

↑ Back to top ↑ Back to list

Being a file owner means handling access requests. Done well, it’s quick and creates clean permissions. Done casually, it’s how organisations end up over-shared.

When someone requests access to your file, you receive an email with their request. Two clicks lets you grant or deny. It’s a small task individually, but for owners of important content, it adds up — and the way you handle each request affects the long-term sharing model of the file.

The temptation is to approve everything quickly and move on. Resist that. Each approval is a permission you’re now responsible for. Take 30 seconds to ask: do they actually need this? At what level? Is the context clear? Does this access need to be temporary?

If a request doesn’t have enough context, ask. If the requested permission level is higher than needed, grant a lower one. If access should be time-bound, make it so. The few extra seconds prevent future audit headaches.

When you’ll use this

• Whenever you receive an access request email.
• When colleagues directly ask for permissions to your files.
• Periodically reviewing pending requests in your file management view.

How to do it

1. Open the access request email (or notification).
2. Review the request — who, what file, why.
3. If context is unclear, ask the requester before approving.
4. Click Approve or Decline.
5. If approving, set the appropriate permission level (usually view).
6. If the access should be temporary, note this and follow up to revoke.
7. If declining, explain why so the requester can find an alternative.

Best practices

• Default to the lowest permission level that meets the need. Edit when view will do is the most common over-share.
• Ask for context if missing. Vague requests deserve clarification, not automatic approval.
• Document temporary grants. If access should expire, add a calendar reminder to revoke.
• Don’t approve out of habit. Each request is an opportunity to do permissions correctly.

Common mistakes

• Auto-approving everything. Convenient now, problematic later.
• Granting edit by default. Most requesters need view, not edit. Don’t grant more than asked.
• Ignoring requests. If you’re not the right owner, redirect the request — don’t leave it in limbo.

↑ Back to top ↑ Back to list

Approval workflows turn ad-hoc ‘can you check this’ email chains into structured, traceable processes. Built into SharePoint, available to most teams, dramatically underused.

Microsoft 365 includes a lightweight approvals feature in Teams and SharePoint, plus more sophisticated workflows in Power Automate. For most everyday approval needs — sign off on a proposal, get a manager’s review of a policy update, route a contract for legal — the built-in tools are enough.

The pattern is: share the file with the approver(s), specifying that you need approval and any deadline; they receive a structured request, can comment or approve in one place; the outcome is recorded and the file gets a clear status. Far cleaner than emailing it round and asking ‘thoughts?’

For frequent or complex approvals (procurement, HR processes, regulated content) build proper Power Automate workflows. For occasional approvals, use Approvals in Teams or SharePoint’s content approval features. For the absolute simplest case, share view-only with comments enabled and ask for explicit sign-off in chat.

When you’ll use this

• Routing documents for management sign-off.
• Getting legal or compliance review on contracts and policies.
• Procurement approvals.
• Anywhere you’d otherwise rely on ‘reply if approved’ emails.

How to do it

1. Identify the approval method appropriate for the situation (Teams Approvals, SharePoint content approval, or Power Automate workflow).
2. In Teams: open the chat and click the + icon, then choose Approvals.
3. Specify the approver(s), include a clear request and the file, and set a deadline.
4. The approver receives a notification and can approve, reject, or request changes.
5. Outcome is recorded — both for audit and for the file’s history.

Best practices

• Use built-in approvals before custom workflows. They handle 80% of cases with no setup.
• Be specific about what you’re asking for. ‘Approve to publish’ is clear; ‘thoughts?’ is not an approval request.
• Include a deadline. Open-ended requests sit in queues forever.
• Document approval outcomes. Save the result back to the file or relevant record.

Common mistakes

• Treating email replies as approval. Hard to track, easy to miss, no audit trail.
• Approving in DM with no record. Six months later, nobody can prove the approval happened.
• Requesting approval with no deadline. Without urgency, requests stagnate.

↑ Back to top ↑ Back to list

SharePoint permissions can feel complicated, but the underlying model is simple: groups grant access to sites, sites contain libraries, libraries contain files. Each layer can override the one above — and that’s where most of the complexity comes from.

By default, files inherit permissions from the library, libraries inherit from the site, and sites inherit from their parent (or have their own as standalone team sites). This inheritance is what makes SharePoint scalable: change permissions at the site level, and files everywhere update automatically.

It’s also where things get tangled. When someone breaks inheritance — granting unique permissions to a single file or library — that file no longer follows the parent’s rules. Done deliberately, this is a useful feature. Done accidentally or repeatedly, it creates ‘permission spaghetti’ that’s nightmare to audit and impossible to manage at scale.

The rule of thumb: design permissions at the site level, leave inheritance intact, and break inheritance only with deliberate intent and a clear reason. Most well-functioning SharePoint sites have minimal unique permissions — they rely on group-based access at the site level instead.

Key terms

Inheritance

By default, child items inherit permissions from their parent. A file inherits from the library, the library inherits from the site.

Unique permissions

When you ‘break inheritance’ on an item, it no longer follows the parent’s rules. Used deliberately, fine. Used carelessly, creates chaos.

SharePoint groups

Site-level groups (Owners, Members, Visitors) that hold permissions and have members. Most sharing happens through these.

Permission levels

Named bundles of capabilities (Read, Contribute, Edit, Full Control). What someone can actually do depends on the level granted to them.

When you’ll use this

• When designing permissions for a new site or library.
• When troubleshooting ‘why can someone see this’ or ‘why can’t they’.
• When auditing existing permissions for compliance.
• When tidying up a site that’s accumulated permission complexity over time.

How to do it

1. For most cases, work at the site level — manage the Members group rather than individual files.
2. If specific content needs different access, create a separate library or document set with its own permissions.
3. Avoid breaking inheritance on individual files unless you genuinely need to.
4. Use the Site permissions view in site settings to see the full picture.
5. When breaking inheritance, document why — future maintainers will thank you.

Best practices

• Design at the site level. Group memberships drive most access; keep it simple.
• Use SharePoint groups, not individual permissions. Group-based access scales; individual access doesn’t.
• Avoid breaking inheritance unless necessary. Each break adds complexity to the audit.
• Document exceptions. If a library has unique permissions, write down why.

Common mistakes

• Breaking inheritance on individual files. Almost always wrong. If unique access is needed, do it at the library or folder level.
• Ignoring SharePoint groups in favour of direct sharing. Direct individual permissions don’t scale and don’t audit cleanly.
• Granting Full Control widely. Reserve for actual administrators. Most users need Edit at most.

↑ Back to top ↑ Back to list

Breaking inheritance is sometimes necessary — but it’s the equivalent of opening the bonnet on your permission model. Do it carefully, document why, and use it sparingly.

By default, a file or library in SharePoint inherits its permissions from the parent site or library. Breaking inheritance means cutting that connection — making the item’s permissions independent. From that point, changes at the parent level no longer affect the item; you have to manage its permissions directly.

There are legitimate reasons to do this: a single sensitive file in an otherwise open library, a library that needs to be visible to a different group than the rest of the site, a project area that needs cross-team access. In each case, breaking inheritance is the right answer.

The risk is creating chaos. Each break is a permission island that has to be managed separately. A site with dozens of broken-inheritance items becomes nearly impossible to audit, and changes that should propagate naturally end up forgotten in disconnected corners.

When you’ll use this

• When a single document or folder needs different access from the rest of the library.
• When a sensitive file lives within a more open site.
• When a sub-area of a site genuinely serves a different audience.
• Almost never for individual files.

How to do it

1. Open the file or library.
2. Go to permissions settings (Manage access > Advanced, or library settings > Permissions).
3. Click Stop inheriting permissions.
4. Confirm.
5. Adjust permissions for the item independently.
6. Document the reason for the break — for future maintainers.

Best practices

• Use the parent site’s permissions before breaking inheritance. If the existing permissions can be made to work, leave inheritance alone.
• Break at the library level, not file level. Library-level uniqueness is manageable; file-level isn’t.
• Document every break. ‘This library has unique permissions because…’ belongs in the site’s documentation.
• Audit broken-inheritance items separately. They don’t show up in normal site permission reviews.

Common mistakes

• Breaking inheritance for one-off file access. Just share the file directly; don’t permanently change the permission model.
• Breaking inheritance and forgetting about it. Now you have a permissions island nobody knows about.
• Breaking inheritance casually. It feels like a small action; the long-term cost is significant.

↑ Back to top ↑ Back to list

Every file in Microsoft 365 lives somewhere. Choosing the right home shapes who can access it, what happens when you leave, and how easily it survives the years.

OneDrive is for personal files — your drafts, your work-in-progress, your individual notes. When you leave the organisation, your OneDrive content goes with you (or gets deleted, depending on policy). It’s tied to you, not to the organisation.

SharePoint is for shared files — team work, organisational records, documents that outlive any individual. It’s tied to the site, the team, the organisation. Members come and go; the content stays. This is where work that matters beyond you should live.

The default mistake is putting team files in OneDrive because that’s where you naturally save things. The cost shows up months or years later when the file’s owner leaves, the team can’t find the document, and the work has to be reconstructed from email threads. The fix is upfront: make a clear choice about where each file belongs, and stick to it.

Why this matters

Picking the wrong location creates predictable, expensive problems:

Team files in OneDrive. The file owner leaves, IT deletes their OneDrive after 30 days, and the team’s history goes with it. This is one of the most common reasons companies lose institutional knowledge.

Personal drafts in a shared Team. Now everyone sees your half-baked work-in-progress, including the version where you wrote ‘this is a stupid idea’ as a placeholder.

Files emailed back and forth. Within an hour, multiple versions exist and nobody knows which is the real one.

Get this right at the start and you avoid all three.

Key terms

OneDrive

Your personal cloud storage. Like your work computer, but in the cloud and accessible from anywhere. Use for: drafts, personal work, 1:1 sharing.

SharePoint

Team and organisational storage. The shared filing cabinet. Use for: team work, official records, anything that needs to outlive the individual.

Teams Files

Files inside a Teams channel — these live in SharePoint behind the scenes. Use for: active team collaboration with chat context.

When you’ll use this

• Every time you create a new file. Decide before you save.
• When migrating an old shared drive to Microsoft 365.
• When inheriting a colleague’s work after they leave.
• When restructuring how a team manages files.

Best practices

• Use OneDrive for solo work and personal drafts. If only you need it, OneDrive is fine.
• Use SharePoint or Teams for shared work. If the team needs it, it should outlive any individual.
• Move files when their nature changes. Started as a personal draft, now a team asset? Move it to SharePoint.
• Ask ‘who needs this when I’m not here?’ . The answer points to the right home.

Common mistakes

• Storing team work in personal OneDrive. The team loses access when you leave. This is the single most common institutional knowledge loss pattern.
• Treating Teams chat as durable file storage. Chat files end up in personal OneDrive. They’re not part of the team’s record.
• Saving everything to SharePoint ‘just in case’. Personal drafts cluttering team sites is also a problem. Solo work belongs in OneDrive.

↑ Back to top ↑ Back to list