Start with who needs the file
A colleague may say “send the supplier a link”, but that sentence does not define who can use it. Is the recipient one named estimator, the supplier’s project team, or anyone who receives a forwarded message? Microsoft distinguishes specific-people links, organisation-only links and Anyone links. An Anyone link can be opened without authentication by anyone holding it. The right starting point is the business relationship and the document, not the easiest button in a share dialog. For a named external counterpart, a specific-people link is usually a clearer expression of the intended audience.
Ask what the recipient actually needs to do. Viewing a signed quotation is different from co-editing a working specification. Make view the default for a final document and grant edit only when the task requires it. Decide whether download is necessary under the available product controls, but do not assume a view-only link prevents a person from photographing or otherwise recording what they can see. Sensitivity still matters. If a document contains other customers’ data, remove or separate that information before sharing; the link type alone cannot make an overbroad document appropriate.
There may be a legitimate case for an Anyone link, such as a low-sensitivity brochure intended for broad distribution. If so, decide that deliberately, constrain its permission and lifetime where the tenant offers those controls, and consider whether publishing the material openly would be simpler. Microsoft notes that Anyone links can be restricted to view and made to expire. These settings are options, not proof that every existing link already has an expiry or that all site policies permit them. Review the actual tenant and site configuration before telling staff which choices exist.
Check the layers that govern the link
In SharePoint and OneDrive, the organisation setting is not the whole story. Microsoft says OneDrive cannot be more permissive than SharePoint, and individual sites can have their own sharing settings. External collaboration settings in Microsoft Entra can also affect guest invitations. This means a user may see a choice greyed out even after an administrator believes external sharing is enabled. Document the intended policy at organisation, site and relevant group level, then verify it with a test user in the actual library. A screenshot of one admin page is not an end-to-end acceptance test.
Defaults matter because busy staff often accept the option already selected. Microsoft lets administrators choose the default link type and whether its default permission is view or edit. Set those defaults to reflect the common safe task, while leaving a documented route for an unusual legitimate case. A default does not replace staff judgement: a named-recipient link to the wrong address still reaches the wrong person. The share dialog should make the audience and permission visible before the sender completes the action, especially for a document with commercial or personal information.
Microsoft also describes controls to restrict external sharing to particular security groups, restrict domains and set guest expiry or reauthentication in some configurations. These are policy tools, each with trade-offs. A domain restriction may be useful when working with a stable supplier domain but can block a legitimate contractor using a different address. Guest expiry may reduce stale access but can disrupt a long project unless someone owns renewal. Specify the business rule, test it with a real partner pattern and tell users whom to contact when a legitimate share is blocked.
Give the share an owner and end point
A link should have a purpose, owner and review point. For a supplier tender, the owner may be the purchasing lead and the review point the bid close. For a design collaboration, it may be the project manager and the end of the working phase. A time limit on an Anyone link addresses one route of access, but the organisation still needs to consider named guest permissions, copied files and other links to the same item. Do not promise that expiring one link retracts every copy already downloaded or every separate grant.
Before a project closes, list the material actually shared, the recipients or link audiences, permissions and intended stop date. Check whether a folder share unintentionally covers documents added later; a narrowly selected file may be easier to reason about than an entire evolving folder. Review access in the product’s current management interface and verify a former collaborator can no longer open the item after removal. Keep the test within approved accounts and sample documents. A policy entry marked “revoked” is only an administrative statement until the access behaviour is checked.
Ownership must survive staff changes. If the employee who created the link leaves, a team owner should still know why the access exists and how to close it. Keep a lightweight register for significant external shares rather than expecting every worker to remember old invitations. It can record document group, external party, business owner, link type, permission and planned review date without storing sensitive link secrets in an open spreadsheet. The aim is to make review and offboarding possible, not to create a parallel access-control system that nobody maintains.
Choose a link for a supplier review
Imagine a Hong Kong wholesaler asking an outside packaging supplier to comment on a draft specification. The file includes dimensions but no customer list. The purchasing lead identifies two supplier contacts, grants them the permission needed to comment or edit the working copy, and records a review date aligned with the quotation cycle. A specific-people link expresses that limited audience. This is a hypothetical design exercise, not a report about a real wholesaler. If the supplier needs to add a third reviewer, the lead revisits the recipient list instead of forwarding a broadly usable link by habit.
Now change the scenario: the wholesaler wants to send the final, public packaging guide to hundreds of resellers. The audience is broad, the document has been approved for distribution and editing is unnecessary. An Anyone link with view-only permission and an appropriate expiry may be a deliberate option if the tenant and site allow it; publishing a public document may be another. The choice changes because the document and audience changed, not because a more permissive setting is inherently better. Check that any expiry will not break a promised customer resource.
For acceptance, test both paths with a sample file and accounts representing a named supplier, an unrelated outsider and a former collaborator. Confirm the intended person can work, the outsider cannot open a named-only share, and access ends when removed or when the applicable link expires. Also check that an organisation-only link cannot be used by the supplier, even if an employee thought it could. Record the actual share type and permission seen in the interface. This practical test catches misunderstandings that a policy sentence or vendor feature list cannot.
Adopt a small sharing decision rule
A useful rule fits on the share request itself: name the outside party, identify the exact file, choose view or edit, select a review point and record who owns the share. The administrator then configures defaults and site limits that support this rule. Make the restricted path easy for normal work, and make broad anonymous access a conscious exception with a reason. Staff training should use examples from their own workflow, such as a draft specification, a final brochure and a confidential price sheet, because those documents call for different choices.
When reviewing existing shares, prioritise sensitive documents, broadly accessible links and access with no current owner. A review should ask whether the recipient still needs the material, whether edit is still required and whether the file itself now contains more information than when first shared. Make changes in a controlled sequence so a live collaboration is not broken without warning. Notify the business owner before changing access where work is active, then verify the resulting permission with a test account. That gives both the customer relationship and the information boundary a chance to be handled properly.
The immediate next step is to select one active external project and trace a single shared document from invitation to closure. Ask the project owner to explain why that audience, permission and duration were chosen, then compare the explanation with the live Microsoft 365 settings. If they differ, correct the setting or the documented decision and test again. Repeat with a low-sensitivity broad-distribution document to show staff why a different choice can be justified. The goal is a repeatable decision that matches the real product controls, rather than a blanket slogan about never sharing.
Before you proceed
- Is the audience named, internal, or anyone with the link?
- Is edit genuinely needed and when should access end?
- Can the team verify removal with a former-user test?
