A Civil Contractor Keeps In-House App Links Intact With Thousands of Programmatic Files.com Folder Locks

A US heavy civil contractor moves earth on work spanning highways, airports, stadiums, mining, and large-scale data centers.

Every job is a project, and every project generates a stream of documents: purchase orders, RFPs, change orders, plan sets, photos from the field. The contractor manages that work through applications its own development team builds in-house, used by office staff and by crews on tablets and phones at the job site. Those applications save their data into shared folders, and they link straight into them. When a user opens a purchase order in an app, the app takes them to that purchase order's directory.

That makes the folder structure part of the applications, not just storage. Every link assumes a directory with a specific name, in a specific place.

One Renamed Folder Broke Every Link That Pointed at It

The contractor had used Dropbox, Egnyte, ShareFile, and SharePoint for shared files, and none of them could hold a directory in place. Anyone with access to a folder could rename it, and people did. A renamed folder still holds its files. But every application link pointing into it now points at nothing.

The only defense was policy. Folder names followed conventions owned by specific departments, and users were expected to leave them alone. A convention is a policy, not a control, and nothing in a general-purpose sharing tool distinguishes a folder an application depends on from any other folder.

This was a standing condition, not an incident. The structure had to be rigid and constantly growing at the same time. Rigid, because a single rename anywhere in the tree broke applications. Growing, because new projects, purchase orders, RFPs, and change orders spawn new directories every day. That combination also ruled out the obvious fix: no systems team can hand-build and hand-protect a tree that gains folders daily across an expanding project portfolio. As the portfolio grew, the folder count multiplied, and the exposure multiplied with it.

The fix had to invert who makes folders. Directories had to be created by software, not people. They had to be locked against rename, move, and delete at the moment of creation. Permissions had to be applied in the same step. And when a project closed, cleanup had to happen without anyone remembering to do it.

The Applications Became the Administrator

The contractor selected Files.com as the storage layer its own applications could administer, and built the governance directly into the apps. Files.com gave the contractor a folder estate that its software creates and the platform enforces, so structure is no longer something people maintain and IT defends.

The team put the folder-governance layer through extensive testing before rolling it out first for the RFP workflow.

Provisioning runs from inside the apps. A user who needs a new purchase order on a project asks for it in the application. The app calls the Files.com REST API with its own API key, creates the folder, and grants the right groups permission to it in the same step. The link the app displays points at a directory the app itself just made, so it is correct by construction. The field applications, built on Microsoft PowerApps, write into the same governed tree.

Protection is applied as the folders are created. Each app-created directory carries the Files.com Lock Subfolders setting, which stops any user from renaming, moving, or deleting it. The contractor applies the locks top-down at the parent level, so one setting protects an entire tree rather than one rule per folder, and enforcement stays fast as the tree runs into thousands of directories. Users still create their own working folders inside a locked purchase order. The skeleton belongs to the system; the contents belong to them.

The lifecycle is automated at the far end too. When a project completes, its tree moves to an archive, and a Files.com Automation purges archived projects after a retention period.

Thousands of Folder Locks, None Applied by Hand

With the governance layer in production, the contractor replaced a folder structure defended by naming conventions with one the platform enforces.

• Thousands of Lock Subfolders settings are live across the system, every one applied programmatically by the applications. No administrator creates or maintains them.
• A broken deep-link is no longer a class of failure. The directories the applications point at can no longer be changed by users, so the links stay valid as the tree multiplies.
• Standing up a new project's structure takes no one's time in IT. One project's subcontracts folder picked up its locked subfolders in a single morning, all created by the application.
• Completed projects clean themselves up. Archive and purge run on their own, so the tree grows only where work is live.

The contractor expects heavier RFP and change-order activity ahead, and the model absorbs it with no added administrative work.

Folder Structure as Application Infrastructure

Today, a user who needs a new purchase order presses a button and works in a folder that already exists, already carries the right permissions, and cannot be renamed out from under the applications that link to it. The systems team no longer polices folder names or chases down broken links. The structure it used to defend with conventions is enforced by Files.com from the moment each folder is created. For a contractor whose own applications deep-link into shared storage, the folder tree was never just storage. It is application infrastructure, and the contractor now provisions and protects it the same way it builds the applications: in code.