Your accountant needs one spreadsheet. A supplier needs a project folder. Neither should gain access to the rest of your business files. SharePoint can support both arrangements, but the result depends on several settings working together.
SharePoint external sharing settings are controlled at organisation and site level. A site can be more restrictive than the organisation, but cannot exceed its sharing limit. For routine business collaboration, a sensible starting point is authenticated guest sharing on approved sites, Specific people links and View permission unless editing is needed. Keep confidential internal material in sites where external sharing is disabled.
This checklist covers SharePoint Online in Microsoft 365 for UK businesses. It walks through the settings, guest access, common errors and a practical acceptance test. For internal access, groups and inheritance, see our SharePoint permissions best practices guide.
Guidance checked against Microsoft documentation on 9 November 2026. The worked example is illustrative; the checklist has not been tested in your tenant. Interface labels and available controls can vary.
- Understand the four sharing levels
- Before you change anything
- 1. Check organisation-level sharing settings
- 2. Set the sharing limit for each site
- 3. Make Specific people and View the default
- 4. Check domains and guest identity policies
- 5. Give guest access an end date and an owner
- A worked example: share an accounts pack with an accountant
- Test what works and what must fail
- Troubleshoot external sharing errors without widening access
- Review existing access before you call the job finished
- Frequently asked questions
- Give external collaboration a clear owner
Understand the four sharing levels
The sharing level decides which kinds of external collaboration are permitted. It does not grant someone access by itself. A person still needs an appropriate invitation, permission or usable sharing link.
| Setting | What It Allows | Practical Decision |
|---|---|---|
| Anyone | Anonymous links to files and folders, alongside authenticated sharing. These links can be forwarded. | Reserve for approved material where access without identity checks is acceptable. |
| New and existing guests | Sharing with authenticated external recipients, including people not yet in your directory. | A useful starting point for ongoing customer, accountant or supplier collaboration. |
| Existing guests | Sharing with guests already in your organisation’s directory. | Use only with a managed guest-onboarding process; directory presence is not approval for every document. |
| Only people in your organization | External sharing is disabled. | Suitable for internal-only sites, such as payroll working files. |
These are Microsoft’s interface labels, including their spelling. Anyone does not make a whole SharePoint site anonymously accessible: anonymous links apply to files and folders. See Microsoft’s external-sharing overview.
Avoid treating Existing guests as a complete approval system. Microsoft’s collaboration planning guidance points out that guests can enter the directory through other routes. Ask who owns the relationship and what the person should access.
Before you change anything
Start with one real collaboration need and one accountable business owner. Record:
- The site URL, owner and reason for sharing.
- The external organisation and intended recipients, using verified contact details.
- The files or folders required, whether editing is necessary and when access should end.
- The current organisation and site settings, including domain restrictions and link defaults.
- Existing guest access and links that a change could interrupt.
- The administrator making the change, approval and planned test.
Use a SharePoint Administrator account for the admin-centre changes below. Being a site owner alone does not let you change the site’s external sharing level. Coordinate Entra policy changes with the identity administrator.
Do not change a tenant-wide policy just because one supplier cannot open a file. First establish whether the block is intentional, whether the right identity was invited and whether the document belongs in an externally shared site.
1. Check organisation-level sharing settings
In the SharePoint admin centre, open Policies > Sharing. Review the separate SharePoint and OneDrive sliders, select the approved sharing levels and save any authorised change.
OneDrive cannot be more permissive than SharePoint. If your organisation allows authenticated guest collaboration, New and existing guests can provide that capability without enabling anonymous links. The decision should cover the wider estate, including existing sites and business workflows, rather than this one request.
Expand More external sharing settings and review who may share externally. Where appropriate, restrict this to designated security groups of trained staff. Record who maintains those groups and how colleagues request access. Review whether guests should be able to share items they do not own.
Use Microsoft’s organisation-level settings guide to check the controls available in your tenant. Keep a before-and-after record so another administrator can understand the change.
2. Set the sharing limit for each site
Open Sites > Active sites, select the intended site, then look under Settings > More sharing settings. Some interfaces also expose a Sharing command. Choose the site’s external sharing level and save. Microsoft documents this route in Change the sharing settings for a site.
Check the URL carefully: a department may use several similarly named sites. For channel sites, identify the actual channel site rather than assuming the parent team’s setting answers the question.
For example, if the organisation permits New and existing guests but a payroll site permits Only people in your organization, external access remains blocked on payroll. Raising the site slider cannot bypass a stricter organisation limit.
A practical pattern is to use dedicated collaboration sites for approved external work. Keep the internal source material separate and publish only the documents the partner needs. This makes the boundary easier for staff to understand and for the owner to review.
3. Make Specific people and View the default
The default link type is what colleagues see first when they share. It is not the maximum permission the system allows.
For a partner collaboration site, consider Specific people as the default link type and View as the default permission. An approved editor can receive Edit when the task calls for it. Check site overrides as well as the organisation default; Microsoft explains these in its default sharing-link guidance.
Explain these distinctions to staff:
- Specific people: intended for named recipients who verify their identity. Forwarding the link does not itself authorise another person.
- People in your organization: an internal link; forwarding it to a supplier does not make it an external invitation.
- People with existing access: sends a route to the item without granting new permission.
- Anyone: possession of the link can be enough to access the item, within the link’s permissions and lifetime.
If Anyone links are genuinely needed, give the exception an owner, approved content scope and expiry. Do not use them as a quick fix for a guest sign-in problem. Also remember that View access alone is not a promise that a recipient cannot download or retain a copy.
4. Check domains and guest identity policies
Domain restrictions can help limit collaboration to approved partners. An allow list names the domains you permit; a block list excludes specified domains. Check the organisation and site lists together, then check Microsoft Entra external collaboration restrictions.
A site-level allow list cannot expand an organisation-level allow list. Enter the partner’s actual email domain rather than its trading name; Microsoft does not support wildcard domain entries. See Microsoft’s domain-restriction guidance.
An allowed domain is a boundary, not proof that every recipient at that company should receive the file. Verify the person and business purpose as well.
Account for the 2026 Entra B2B changes
Older instructions may tell you to enable B2B integration using PowerShell. Microsoft states that it enabled the integration for new external sharing in commercial tenants between May and July 2026; the old EnableAzureADB2BIntegration switch no longer controls that behaviour there.
Microsoft also began retiring legacy SharePoint one-time-passcode authentication in October 2026. Entra B2B email passcodes remain supported. When retirement reaches a tenant, an older Specific people link can require a matching Entra B2B guest account. If the account is missing, an authorised administrator can create it, or an authorised sharer can reshare content to establish the guest identity.
Check Microsoft’s current B2B transition guidance before diagnosing an old link. This is a reason to check the identity behind the invitation, not a reason to allow anonymous access. Include applicable MFA and Conditional Access policies in the identity administrator’s review; availability and licensing depend on your setup. Our Microsoft 365 authentication guide explains the wider role of additional sign-in checks.
5. Give guest access an end date and an owner
Choose a review period that reflects the work. For example, an owner might review access after a short supplier project or at the end of an annual accounts exercise. These are business decisions, not universal Microsoft defaults.
Where suitable, configure guest access expiration and record who will review renewal requests. Guest expiration, Anyone-link expiration and deleting a guest account are different actions. Expiring SharePoint access does not delete the Entra identity or necessarily remove access to other resources.
Microsoft also notes that the guest-expiration policy does not apply retrospectively to permissions granted before the policy was enabled. Group-based access needs separate attention. See Manage guest expiration for a site.
At closure, inspect Manage access on the relevant items, remove unnecessary links and direct permissions, and review group or team membership. If the employee who managed the relationship leaves, assign a successor using the Microsoft 365 employee offboarding checklist.
A worked example: share an accounts pack with an accountant
Imagine a UK business preparing its annual accounts. The accountant needs a small document pack, while payroll working files must stay internal.
| Decision | Example Arrangement | Evidence to Keep |
|---|---|---|
| Location | A dedicated accountant collaboration site; internal payroll remains elsewhere with external sharing off. | Site URLs and the data owner’s approval. |
| Sharing level | New and existing guests within the organisation’s approved limit. | Recorded organisation and site values. |
| Recipients | Named accountant contacts whose addresses the finance owner has verified. | Approval in a restricted ticket. |
| Permission | Specific people, View for the final pack; Edit only for an agreed working document. | Item-level permission check. |
| Lifecycle | Finance owner reviews access when the exercise closes. | Named owner and review date. |
| Verification | Intended guest succeeds; uninvited recipient and post-removal tests fail. | Test results, time and tester. |
Use dummy documents for the initial test. Do not upload the live payroll export merely to find out whether the sharing arrangement works. Once the test passes, the finance owner should check the actual pack before it is released.
Test what works and what must fail
A successful invitation proves only part of the setup. Run these checks with approved external test accounts and non-sensitive files. Keep the test accounts separate from administrator sessions.
| Test | Expected Result | If the Result Is Wrong |
|---|---|---|
| Intended guest opens the Specific people link | The verified recipient can open the intended item after the required identity checks. | Check the invited address, guest identity and applicable policies. |
| A second, uninvited external account opens the forwarded link | Access is denied unless that account has another legitimate permission. | Inspect link type, direct access and group membership. |
| A View-only guest tries to edit | Editing is unavailable. | Check whether another permission path grants Edit. |
| Guest tries an unrelated restricted location | Access is denied. | Review site membership and the scope originally shared. |
| Owner removes the test guest’s access and retests | The guest can no longer open the online item after the change takes effect. | Check remaining links, direct permissions and memberships. |
An unexpected pass on a denial test should stop the rollout until you understand it. Record the link type, account used, result and follow-up owner. Avoid putting live sharing URLs, passcodes or customer data into a broadly visible ticket.
Revocation cannot retrieve a copy that someone already downloaded. Treat online access testing and the handling of exported files as separate responsibilities.
Troubleshoot external sharing errors without widening access
Capture the exact message, affected site, invited identity and time. Start with the narrowest relevant control. The following codes are documented in Microsoft’s sharing-error reference.
| Error or Symptom | What to Check | Sensible Next Step |
|---|---|---|
| OSE201 or OSE204 | Organisation-level or site-level external sharing is disabled. | Ask the owner whether external collaboration is approved for this location. |
| OSE202 or OSE205 | Sharing is limited to existing guests. | Check the guest-onboarding process and intended directory identity. |
| OSE304 | The person sharing is outside the security groups allowed to share with guests. | Review that employee’s authorised group membership. |
| OSE401–OSE404 | Organisation or site domain restrictions block the recipient. | Verify the address and approved partner domain before requesting an exception. |
| Guest signs in but sees Access denied | Wrong identity, missing permission, expired access or another applicable policy. | Test the invited identity separately; inspect Manage access and relevant identity records. |
| An older link stopped working | Guest identity and the 2026 authentication transition, alongside ordinary permission checks. | Confirm a matching B2B guest and reshare through the approved process if needed. |
If a control is doing its intended job, explain the approved route to the requester. A fix might be moving the approved document to the collaboration site, correcting an email address or onboarding a guest. It need not be a broader policy change.
Review existing access before you call the job finished
Changing a default does not prove that old links and permissions meet the new policy. Review the existing estate as a separate task, prioritising sensitive sites and active partner relationships.
For each reviewed site, the owner should be able to answer: Who is outside the business? What can they open? Why do they still need it? Who will remove it?
Keep this compact sign-off record:
- Boundary: organisation limit, site limit, approved domains and any exceptions.
- Scope: shared content, named recipients and permission level.
- Identity: invitation and applicable guest sign-in checks verified.
- Tests: expected access, denied access and removal results recorded.
- Lifecycle: business owner, review date and closure action agreed.
Turning external sharing off and back on can restore access through existing permissions and links. Remove unwanted access explicitly rather than relying on a temporary switch-off as permanent cleanup. Keep a record of outstanding exceptions with an owner and deadline.
Frequently asked questions
Give external collaboration a clear owner
Choose one active partner site and run the access tests with its business owner. Record the settings, expected results and next review date. If a test fails or nobody owns the guest lifecycle, TechVertu’s Microsoft 365 services can help review your configuration and agree the next steps.

Lets Talk!
If you have additional comments or questions about this article, you can share them in this section.
You mention group-based access needs separate attention with guest expiry — how should we handle guests whose access comes through a SharePoint group?
Guest expiration does not necessarily reach access a guest holds through group membership, so treat each group as its own access route. List the SharePoint, Microsoft 365 and security groups containing the guest, remove them at closure, then retest with the guest account to confirm access is blocked. Record each route in your review register. The companion permissions guide covers checking and removing these access routes.