Four real ways to share files in SharePoint, and when each one actually fits:
- 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.
- 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.
- 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.
- 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 · Best practices · When would you actually use this?
The four link types, explained
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 DisabledPer-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.
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