SharePoint File Sharing: Best Practices and Approaches

Four real ways to share files in SharePoint, and when each one actually fits:


  1. Direct links: generate a view-only or edit link, optionally with an expiration date and password. Best for a quick one-off share, not for ongoing collaboration structure.
  2. Managed document libraries: structure permissions at the library level instead of sharing individual files. Better for teams collaborating on an ongoing project, since it maintains hierarchy and compliance instead of a pile of ad-hoc links.
  3. Sharing through Teams: files shared in a Teams chat land in SharePoint automatically, accessible without leaving the conversation. Good for real-time collaboration where discussion and editing happen together.
  4. External sharing with guest access: lets people outside your org access specific files without a Microsoft account — pair this with MFA and conditional access, or it’s a real exposure risk.

In this post: The four link types, explained · Setting the tenant-wide default · Sensitivity labels can override the link type entirely · Auditing who a file is actually shared with · Best practices · When would you actually use this? · Related reading


When you click “Share” on a file, the link-type picker is where most of the actual risk decision happens — it’s worth knowing exactly what each option does before defaulting to whichever one is fastest:

  • Anyone with the link: no sign-in required at all — if the URL leaks (forwarded, pasted somewhere public, indexed), anyone with it gets in. The broadest option and the one worth an expiration date every time.
  • People in [organization]: anyone signed into your tenant, but nobody external. A safe middle ground for internal-only content that still needs to move outside a single team’s permission structure.
  • People with existing access: doesn’t grant anything new — just gives a shareable link to someone who already has permission, useful for a colleague who needs the URL rather than a fresh invite.
  • Specific people: the tightest option — only the named individuals (internal or external) can use the link, even if it’s forwarded elsewhere.

Setting the tenant-wide default

Individual link-type choices only matter within whatever ceiling the tenant-wide external sharing setting allows — if external sharing is fully locked down at the tenant level, nobody can generate an “Anyone” link no matter what they pick. That ceiling has four levels, from most to least permissive: Anyone, New and existing guests, Existing guests only, and Only people in your organization. Set it via the SharePoint admin center (Policies > Sharing) or PowerShell:

Connect-SPOService -Url https://contoso-admin.sharepoint.com

# Tenant-wide ceiling
Set-SPOTenant -SharingCapability ExternalUserAndGuestSharing

# Override for one sensitive site (tighter than the tenant default, not looser)
Set-SPOSite -Identity https://contoso.sharepoint.com/sites/Finance -SharingCapability Disabled

Per-site settings can only be as permissive as the tenant-wide ceiling, never more — if you need a site to allow broader sharing than the rest of the tenant, the tenant-wide setting has to move first.


Everything above is about the sharing ceiling and the link picker — but a Microsoft Purview sensitivity label applied to a site, a document library, or an individual file sits above both and can override the choice entirely. A site or Team labeled “Confidential” (or whatever your organization calls it) can have external sharing automatically disabled the moment the label is applied, regardless of what the tenant or site-level sharing setting otherwise allows — the user never even sees an “Anyone” option to accidentally pick.

Worth knowing about specifically right now: Microsoft is rolling out a feature (preview started August 2026, GA expected October 2026) that lets a document library’s default sensitivity label apply automatically to files that already exist in it, not just new uploads. If that library’s default label restricts sharing, files that were previously shareable can lose that ability retroactively once the label is auto-applied. Worth auditing what’s actually shared broadly in labeled libraries before this rolls out to your tenant, rather than after someone notices a link stopped working.


Auditing who a file is actually shared with

Everything above governs what link types are even possible — it doesn’t answer the question that actually matters during a review: which links exist right now, and who can use them. Get-PnPFileSharingLink returns exactly that per file, including link scope, expiration, and (for “Specific people” links) who was actually granted access:

Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -Interactive

# Every sharing link on every file in a library, in one pass
Get-PnPFileInFolder -FolderSiteRelativeUrl "Shared Documents" -Recurse -ExcludeSystemFolders |
    Get-PnPFileSharingLink |
    Select-Object -ExpandProperty Link |
    Select-Object Scope, WebUrl, @{N="Expiration"; E={$_.Expiration}}

The Scope property is the field worth filtering on first for a time-pressured review — it distinguishes a true “Anyone” (anonymous) link from an organization-only or specific-people link, so the highest-exposure links surface before working through a library in file order. Combine with the tenant-wide sharing capability set above and a library’s applied sensitivity label to get the full picture: what’s technically possible, what’s actually been shared, and what a label might retroactively lock down — three separate questions this section, the one before it, and the one before that each answer on their own.


Best practices
  • Links over attachments — recipients always get the current version, and you’re not duplicating files across inboxes.
  • Set expiry dates on external links — indefinite access to a file is rarely actually intended, just unmanaged.
  • Default to view-only unless someone genuinely needs to edit — not every recipient needs write access.
  • Turn on audit logs and alerts for anything sensitive, so you know who accessed or changed it.
  • Restrict external sharing by domain where the content warrants it, rather than leaving it wide open.
  • Use SharePoint groups, not individual permissions — assigning access one person at a time doesn’t scale and gets inconsistent fast.

Set expiry dates on external links — indefinite access to a file is rarely actually intended, just unmanaged.

When would you actually use this?
  • You need to send one file to someone outside the team, once — a direct link with an expiration date, not a permanent library restructure.
  • A team is going to collaborate on a growing set of documents over months — set up managed library permissions from the start rather than retrofitting structure onto a pile of shared links later.
  • A vendor or client needs ongoing access to specific project files — guest access with conditional access policies, not an ad-hoc link that never expires.


That wraps it up. Drop a comment if you get stuck.


App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning

Leave a Comment

Your email address will not be published. Required fields are marked *