BluSky Restoration Replaces SharePoint Guest Links and Manual Azure Blob Delivery With Expiring Files.com Data Rooms

BluSky Restoration Contractors fixes broken buildings. A national restoration and reconstruction firm, it repairs and rebuilds commercial, industrial, multifamily, and residential properties damaged by water, fire, and storms from offices across the United States. Its customers are property owners and managers, and just as much the insurance community behind them: BluSky positions itself as a preferred contractor for the insurers and claims managers who pay for restoration work.

That position comes with a paper trail. Restoration projects live inside insurance claims, and claims generate files that have to leave the company: records for clients, documentation for insurers, and case files for outside counsel when a loss turns into a dispute. Every case means files crossing the company boundary, and every set of files is meant for exactly one recipient.

Case Files That Outgrew Guest Links

BluSky handled that distribution the way most companies do: with what was already lying around. Files bound for outside counsel and other third parties went out through SharePoint and OneDrive guest-access links. Meanwhile, a Microsoft Dynamics CRM process generated output files per client and wrote them into Azure Blob Storage, where the clients those files were made for had no way to authenticate and pull only their own data. Every delivery out of Blob needed a person at BluSky brokering the handoff.

Guest links were not much better on the other path. They gave BluSky no per-case segmentation, no way to guarantee that file movement stayed one-way, and no lifecycle: access was opened by hand and had to be remembered and closed by hand as cases opened and shut. The workload was heavy, too. External transfers ran from 500 GB to more than a terabyte. That is a scale guest-link sharing was never designed to carry.

What the Replacement Had to Guarantee

None of this was carelessness. The Dynamics process worked: it created the users, ran the workflow, and produced the files, and rebuilding it just to change how those files got delivered was never on the table. The recipients made the problem harder than an ordinary sharing setup could absorb. They are transient external users, created programmatically by the upstream process as cases open, and some of the source containers in Azure are ephemeral, dying the moment their contents are copied out.

The requirements BluSky set for a fix were explicit: file movement is one-way, with no uploads. Files are protected through authenticated, permission-segmented access. Every client's data is segmented from every other client's by permissions. Read as a specification, that list is also a verdict, because it describes everything guest-link sharing was not doing.

BluSky selected Files.com to provide that layer: a governed data room per case, sitting in front of the Azure storage and the Dynamics process that were already there.

A Data Room for Every Case, Created by Code

Files.com became the authenticated front door on infrastructure BluSky already ran, with the whole lifecycle of a delivery handled by code.

Separation comes from Files.com Workspaces. Each case or client gets its own walled-off area inside the BluSky site, with its own users, folders, and group-governed permissions. A user provisioned into one workspace sees that workspace and nothing else, so segmentation is enforced by the structure itself rather than by anyone's care in building a link.

Provisioning comes from the Files.com REST API. When a case needs a data room, code creates a group, creates the users, stands up the workspace, and grants the group its permissions on it. BluSky brought in an external development partner to wrap that sequence in an Azure Functions integration, so workspaces, users, and groups are provisioned end to end without an administrator in the loop.

Ingestion comes from Files.com Automations and the platform's Azure Blob integration. BluSky links to a blob programmatically, copies its files into the case's folder on Files.com, and lets the container go; some of those containers are ephemeral and die once the copy completes. The Dynamics process that produces the files never changed.

Governance is built into the workspace. Access through the web client is download-only, so movement stays one-way. Content expires after roughly two weeks, so a case's files are available for the delivery and then gone, with no cleanup pass required.

Delivery With Nobody in the Middle

With the workspace pattern in production, BluSky replaced open-ended guest links and hand-brokered Blob deliveries with case-scoped access that clients reach on their own. The layer has handled external transfers from 500 GB to more than a terabyte.

A New Front Door on the Existing Workflow

Today, when the Dynamics process finishes generating a client's files, delivery is a property of the system rather than a task on someone's list. The files land in a Files.com workspace built for that case, the client signs in and takes what is theirs, and roughly two weeks later the files are gone. What used to require a person moving files out of Blob, or a guest link someone created and later had to remember, now requires nobody.

BluSky got there without rebuilding anything. The CRM process still generates the users and the files, and Azure Blob still stages its output. What changed is the front door: Files.com is where authentication, segmentation, and expiry now live, layered over systems that were already doing their jobs. The part that compounds is the shape of the fix itself: the next case, like the last one, is an API call.