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

A national restoration contractor fixes broken buildings. 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: the contractor 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

The contractor handled that distribution with the tools it already had. 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, and the contractor wanted each client to authenticate and pull only its own data from there. Every delivery out of Blob needed a person at the contractor brokering the handoff.

On the other path, the contractor wanted more than a guest link offers: per-case segmentation, file movement guaranteed to stay one-way, and a lifecycle that opens and closes access as cases open and shut, with nobody doing either by hand. The workload was heavy, too. External transfers ran into the terabytes, and the contractor wanted a layer built to carry that scale.

What the Replacement Had to Guarantee

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 the contractor 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. And access opens and closes with the case, with nobody at the contractor in the loop.

The contractor 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 the contractor 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 contractor's 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.

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. The contractor 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. The contractor 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 a set period, 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, the contractor replaced guest links and hand-brokered Blob deliveries with case-scoped access that clients reach on their own. The layer has handled external transfers running into the terabytes.

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 once the window closes the files are gone. What used to require a person moving files out of Blob or building a guest link by hand now requires nobody.

The contractor 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.