A Building Systems Integrator Delivers Files to Recipients Without Accounts on Locked, Expiring Files.com Links

A North American building systems integrator designs, installs, and services building automation, security and life safety, and turnkey energy systems for commercial and institutional customers. After years as the North American building-technology arm of a global industrial group, it took the parent’s name outright.

That unification set the requirement. A systems integrator’s files leave the company by definition: project managers send bid drawings, specifications, and quotes to customers and outside bidders, and technical support sends troubleshooting files and fix executables to technicians standing at a customer’s own machine, where a corporate login does not exist. The parent absorbing all of this is a global industrial group, and its Microsoft 365 estate is governed accordingly: anonymous and public-facing links are prohibited, and any recipient of a shared file must hold an account in the system. Folding the integrator into the parent meant folding a business built on sending files outward into a tenant where, as a matter of policy, files do not go outward without an account.

One Company, Two Tenants, and Files That Have to Go Outward

The integrator’s offices joined the parent’s infrastructure in waves, and every office had to keep sending files to customers and technicians from the day it moved. The integrator and its parent also sat on separate Microsoft 365 tenants, so the two halves of one company were external to each other: an employee of the integrator and a colleague at the parent needed a governed way to exchange a file across that boundary.

The tools in place set the bar the replacement had to clear. The integrator’s standard mechanism was a OneDrive link that expired after 24 hours. For a project manager mid-bid, that meant re-sending the same drawings to the same customer over and over while the customer waited. For technical support it was worse: fix executables stay valid 90 days or longer, so a technician at a customer’s machine routinely found the link dead before the work was done. Email was no fallback, because bid drawings and specifications routinely exceeded the roughly 20 MB attachment limit. The remaining route was slower still: to send a large file to an outside party, someone had to open an IT ticket and have that person provisioned as a contact in Azure first.

The integrator wanted one governed path for every file that leaves the company, whichever business unit sends it. And it wanted that path live in each office as that office joined the parent’s tenant, with hundreds of employees moving in successive waves.

Why Another Storage Platform Was Never the Answer

The obvious move was a sync-and-store platform, and that failed on governance, not on features.

Under the parent’s data-classification rules, every system that holds files is a repository to classify and govern. Sync-and-store platforms were disqualified precisely because they are good at storage, and storage was not the job. Ignite, the closest functional fit, required two separate links for a single exchange, one to upload and one to download.

So the requirements were unusual. The replacement had to deliver files to recipients who hold no account and never will, without using an anonymous public link, a combination OneDrive’s link model could not deliver under that policy. It had to carry a two-way exchange on a single link. It had to be built for files to pass through rather than accumulate, so it could never harden into another storage system the parent would have to classify. It had to give IT one managed surface serving both the parent’s and the integrator’s domains. And it had to roll out office by office as each one joined the parent’s tenant.

The integrator selected Files.com to be that surface.

Recipient-Locked Links on an Expiry Clock

What the integrator built on Files.com was a governed layer that files pass through on their way out of the company, and every configuration choice served that idea.

Identity spans the merge. Entra ID single sign-on covers both domains, so employees on either side of the tenant boundary sign in to the same platform.

Delivery works without anonymity, which is the move that meets the policy. Every outbound file goes as a Files.com share link that can be restricted to a specific recipient’s email address, with registration required to open it. The recipient needs no account at the parent, no account at the integrator, and no software; they register through Files.com in a browser. But the link is neither anonymous nor public-facing: forwarded to anyone else, it will not open. IT tested exactly that, forwarding links and attempting unauthenticated access, and confirmed the registration requirement blocks them. The parent’s policy prohibits anonymous links, not external delivery, and a recipient-locked link is not an anonymous link. Password protection and expiration can be set by policy rather than fixed at 24 hours.

Ephemerality is enforced, not encouraged. Files expire a set number of days after their last modification, with a trash retention period behind that. That gives recipients weeks to retrieve a transfer, including support executables that may remain valid for 90 days or longer, rather than the old one-day deadline. Anything durable moves to SharePoint or OneDrive, which remain the systems of record. Files.com holds a file for exactly as long as a transfer needs it.

Access logs and exportable reporting cover logins, file access, and expired links, so IT can show rather than assert what left the company and who received it. The rollout ran behind each migration wave, the platform’s own domain moved from the integrator’s old brand to the parent’s along the way, and the integrator’s IT team now runs the platform on its own.

One Governed Way for Files to Leave the Company

With Files.com in production, the integrator replaced a 24-hour link, an IT ticket queue, and a 20 MB attachment ceiling with one governed way for files to leave the company.

• Three core sharing workflows run on Files.com from the day an office joins the parent’s tenant: customer bid documents, technician file delivery, and exchange between the integrator and its parent.
• Recipient access went from a 24-hour deadline to a policy-governed duration. Support executables that stay valid for 90 days or longer can be made available for weeks per transfer instead of a single day.
• Bidding is no longer bounded by email. Drawings and specifications above the 20 MB attachment limit go to outside bidders as password-protected, expiring links, and engineering management sends HVAC system schematics to iPads in the field.
• A forwarded link opens for nobody but its recipient, and every business unit sends through the same IT-managed platform, with the large majority of accounts already on the parent’s domain.

The compounding result is that each office joining the parent’s tenant lands on a platform already in production, so project managers and technicians send files the same way on their first day as on their last. And the exchange between the integrator’s and the parent’s employees, two halves of one company that the tenant boundary treats as strangers, is now the platform’s largest use case by volume. Files.com is how the company works as one while the merge completes.

Transfer, Not Storage

What changed underneath is that external sharing is now part of the company’s governed infrastructure, with one owner, one audit trail, and one set of rules. The integrator did not find a better place to keep files. Under the parent’s data-classification rules, another repository was never the goal. It built a governed layer on Files.com that files pass through on their way somewhere else, and that is exactly what keeps it allowable.