Understanding Sharing and Access Requests
Sharing in SharePoint lets a user grant access to a file, folder, or site to another person without needing site-owner rights to manage the full permission structure. When a user without access clicks a link or navigates to content they can't open, SharePoint can surface an access request form instead of a dead end, routing the request to someone with the authority to approve it. Together, sharing links and access requests form the self-service layer of SharePoint's permission model, reducing the load on IT and site owners while still keeping every grant auditable through the sharing report and audit logs.
Cricket analogy: It's like a stadium's hospitality box: the box holder can hand a guest pass to a colleague without going through the stadium's main ticketing office, but if someone without a pass tries to walk in, security routes them to the box holder for approval rather than turning them away outright.
Sharing Link Types and Scope
When a user shares a file or folder, SharePoint offers several link types with different scope: 'Specific people' links only work for the named recipients and require sign-in verification; 'People in your organization' links work for anyone signed into the tenant; 'Anyone' links (if enabled by the tenant admin) work for anybody with the URL, with no sign-in required. Each link can also be configured as View or Edit, can carry an expiration date, and—for Anyone links—a password. Admins control the ceiling for what's possible at the tenant, site, or OneDrive level; a user can never share more broadly than the org-wide external sharing policy allows, even if the link UI appears to offer it.
Cricket analogy: An 'Anyone' link is like a free-to-air broadcast anyone can tune into, a 'People in your organization' link is like a members-only stand requiring a club card, and a 'Specific people' link is like a personally named guest pass that only works for that one invitee, checked at the gate.
External Sharing and Guest Access
External sharing lets users outside the tenant—vendors, clients, contractors—access specific SharePoint content without a full internal account. When a tenant admin enables external sharing, an invited external user is added to Azure AD as a B2B guest account and authenticates with their own organizational or Microsoft identity. Admins can scope this at three levels that nest inside each other: the SharePoint tenant admin center sets the overall ceiling (e.g., 'New and existing guests'), individual site collections can be restricted further, and OneDrive has its own separate external sharing setting. A common governance pattern is to allow external sharing tenant-wide but restrict it to a small set of vetted 'client collaboration' site collections, keeping most internal sites closed to guests entirely.
Cricket analogy: It's like a stadium issuing a temporary media pass to a visiting journalist instead of a full season ticket: the journalist (guest) gets scoped access to the press box for one match, the stadium's overall policy sets what passes are even possible, and specific stands can be marked off-limits regardless.
When a request-access flow is triggered, SharePoint routes the request to the site's owners (or to a specific person configured on the site's 'Access Requests Settings' page), who see a notification with the requester's identity, the resource requested, and an optional message. The owner can approve, which grants the requester the default access level configured for the site, or deny, which sends a rejection notice. Site owners can also disable access requests entirely, in which case unauthorized users simply see an 'access denied' message with no path to request it, which is appropriate for highly sensitive sites where access should only ever be provisioned proactively by an administrator.
Cricket analogy: It's like a fan without a ticket approaching the gate and having their request routed to the match referee, who can wave them through to a designated overflow section or turn them away outright, versus a VIP enclosure where the gate simply has no request process at all.
Sharing activity is logged and reportable: the 'Access Requests and Invitations' page and the Microsoft 365 audit log (searchable via the Microsoft Purview compliance portal) both record who shared what, with whom, and when. Site owners can also run the 'Check Permissions' tool on any file to see exactly why a given user has (or lacks) access, tracing it back to the specific link, group membership, or direct grant.
# Inspect and manage sharing settings for a site collection using PnP PowerShell
Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/ClientCollab" -Interactive
# Check the site's current sharing capability (Disabled, ExistingExternalUserSharingOnly, ExternalUserSharingOnly, ExternalUserAndGuestSharing)
Get-PnPTenantSite -Url "https://contoso.sharepoint.com/sites/ClientCollab" | Select-Object SharingCapability
# Restrict this specific site to existing external users only, even if the tenant allows more
Set-PnPTenantSite -Url "https://contoso.sharepoint.com/sites/ClientCollab" -SharingCapability ExistingExternalUserSharingOnly
# Create a view-only sharing link with a 30-day expiration for a specific file
$file = Get-PnPFile -Url "/sites/ClientCollab/Shared Documents/Proposal.docx"
New-PnPFileSharingLink -Identity "/sites/ClientCollab/Shared Documents/Proposal.docx" -Type View -Scope Anonymous -ExpirationDateTime (Get-Date).AddDays(30)- Sharing lets users grant access to specific files, folders, or sites without needing full site-owner permissions.
- Link scope ranges from 'Specific people' to 'People in your organization' to 'Anyone,' each with View/Edit and optional expiration or password.
- The org-wide, site-level, and OneDrive-level sharing policies nest together and set the ceiling on what any user can actually share.
- External sharing adds vendors, clients, or contractors as Azure AD B2B guest accounts scoped to specific content.
- Access requests route unauthorized users' requests to site owners for approval, avoiding a dead-end 'access denied' page.
- Owners can disable access requests entirely for highly sensitive sites, requiring access to be provisioned proactively instead.
- The Check Permissions tool and Microsoft Purview audit log make sharing activity traceable and auditable.
Practice what you learned
1. What determines the maximum scope a user can choose when creating a sharing link for a file?
2. How is an external collaborator typically provisioned when invited to a SharePoint site?
3. What happens when a site owner disables access requests on a highly sensitive site?
4. Which tool lets a site owner trace exactly why a specific user has (or lacks) access to a file?
5. What distinguishes an 'Anyone' sharing link from a 'People in your organization' link?
Was this page helpful?
You May Also Like
Permission Levels and Groups
How SharePoint controls who can do what on a site through permission levels, SharePoint groups, and inheritance.
Information Governance
The policies, labels, and lifecycle controls organizations use in SharePoint to manage content responsibly from creation to disposal.
Site Provisioning
How new SharePoint sites get created, templated, and governed at scale, from self-service creation to automated provisioning pipelines.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics