Auditable External Sharing Without a SharePoint Migration: A Cosmetics Manufacturer’s Path Away From Microsoft 365 Guest Access

A global skin care and cosmetics manufacturer is fully integrated. It runs its own research, its own manufacturing, and its own global distribution, which means a steady stream of files has to cross the company boundary: to raw-material vendors, contract partners, and the auditors who arrive every year.

Inside that boundary, everything lives in Microsoft 365. SharePoint Online and Teams are the backbone for user content and personal productivity, and the company had no intention of changing that. The problem was the edge. Microsoft 365 is built for collaboration inside a tenant. Reaching someone outside it meant a guest account.

External Sharing Sat Outside the Microsoft 365 Backbone

The standing answer for outside access was Microsoft Remote Guest Access, a mechanism built for collaboration inside the tenant rather than for time-boxed vendor and auditor engagements. Every vendor, auditor, or contract partner who needed files meant a guest account granted into shared content. And the need recurred on a schedule: each tax season brought a fresh wave of auditors who needed access for a few months and then needed it gone. The company wanted external access scoped to a folder, set to expire with the engagement, and recorded in one place.

The diagnosis was simple: the company was running its external file exchange on mechanisms built for internal collaboration, and the cost landed on the people accountable for security and administration.

The Fix Had to Complement Microsoft 365, Not Compete With It

The obvious fixes were all wrong. Moving content off Microsoft 365 was never on the table. SharePoint and Teams are where the business actually works, and the IT team's stated requirement was a platform that complements Microsoft 365 rather than competing with it. So external sharing had to be carved off the estate without forcing a single business user to change where they keep their files. And the change could not be a big-bang migration of every external relationship at once; it had to absorb requests as they came.

The requests kept recurring, the administration burden kept climbing, and the company decided to move external access off guest accounts wherever it could. What it needed was a layer where access for an outside party is easy to grant, easy for them to use, recorded every time, and gone when the engagement ends, while internal content stays in SharePoint. The company selected Files.com to be that layer.

An External-Facing Layer Kept in Sync With SharePoint

Files.com became the company's external-facing file platform, sitting beside Microsoft 365 rather than in place of it.

The company connected SharePoint Online to Files.com, with one-way and two-way Syncs keeping designated folders matched. Internal teams now keep working in SharePoint, while external parties work on Files.com. Internal staff sign in to Files.com through single sign-on against Azure Active Directory, so their access follows corporate identity.

External relationships moved to Files.com followed one pattern. Each engagement received a shared folder holding internal staff and external users side by side, typically a handful of each. Accounts for short engagements carried access-expiration dates, so an auditor's credentials could be set to end with the audit. An inactivity rule disables any external account nobody is using, with re-enable on request. Dormant access shuts itself off by default.

The company also built a Microsoft Form intake that used Power Automate and the Files.com API to create the folder, user, and permissions. An external-sharing request became a repeatable form submission instead of a guest account set up by hand. For one-off exchanges, Files.com Share Links send files out and Inboxes collect them in, with access recorded on the same platform.

Demand Moved Off Guest Access Without a Mandate

With the layer in production, the company began moving external-sharing requests off guest accounts. Each relationship is scoped to the right folders, logged in one place, and set to expire with the engagement.

The more telling result was behavioral. Named users kept growing after go-live, driven by staff who had used guest access asking to be moved onto Files.com. The administrators who once handled guest access now route those requests to the Files.com team. Adoption came from pull, not mandate.

Fixing the Boundary Without Touching the Backbone

Today, when someone at the company needs to exchange files with an outside party, the answer is increasingly a governed grant instead of a guest account: a folder, a credential with an end date, and a record of every access. The engagement ends, and the access ends with it.

Microsoft 365 never moved. Nobody was retrained, no SharePoint content was migrated, and no SharePoint cutover was ever scheduled. Files.com carved the external-facing workload off the estate, kept it synced with SharePoint, and let demand do the retiring, one request at a time. Fixing external sharing did not require replacing the platform the company works in. It required giving the boundary a platform of its own.