Rimkus Automates External SharePoint Access for 150 New Projects a Day With Files.com

Rimkus is a global engineering and technical consulting firm working across forensics, engineering and construction, healthcare, industrial, and product development. The firm operates from roughly 100 offices worldwide.

All of that work is organized as discrete jobs. Each engagement is its own project, with its own SharePoint site, its own files (AutoCAD drawings, PDFs, photos, video, audio), and its own set of outside parties: the client, counsel, consultants, vendors. Rimkus opens roughly 150 new projects every working day, and its project managers engage third parties from the first hour. The firm set itself a blunt requirement to match: within 15 minutes of a job being created, people outside Rimkus need a working way to send the project files and receive them back.

Rimkus selected Files.com as the exchange layer and built the share path into project creation itself. The same pipeline that provisions each SharePoint site also provisions its Files.com access.

External Access Was Built by Hand, One Project at a Time

Standing up that access was manual. For every project, user accounts, folders, and permissions were created by hand or by bespoke PowerShell, and different business units ran different tools with no firm-wide standard. Ad hoc sharing ran through an SFTP server the team maintained itself, over links that expired on a fixed 7-to-14-day timer: staff selected the files, dropped them in, generated a link, sent it, and repeated the whole exercise when the clock ran out.

“The link expires after 7 days or 14 days, and we have to select the files and send them back and forth. It’s very cumbersome and hard to manage.”

The lifecycle only ran in one direction. There was no automated decommissioning at project close, so external accounts and access outlived the jobs that justified them.

The cost landed on the people closest to the client. A project manager kicking off a job needed IT work done before the client could send the first file, and at 150 new projects a day, that put a standing internal queue between Rimkus and the opening hours of every engagement.

Scale ruled out fixing it with more effort. Rimkus has more than 20,000 active SharePoint project sites, one per job, out of some 50,000 to 60,000 created over the years, and the count grows daily. SharePoint is also the system of record: project files are collected and worked on there, so any exchange platform had to deliver into it rather than hold a second copy beside it. Anything that needed a person per project, or a separate connection per site, would have collapsed under the volume on day one.

What a Firm-Wide Standard Had to Do

As project volume grew, and as the firm shut off USB drives as a way of exchanging files with outside parties, Rimkus needed one standard electronic path in place of the patchwork, as part of a broader transformation agenda to standardize how the firm operates.

That standard had a specific shape. It had to sit on top of SharePoint rather than beside it, so project data was never duplicated into a second system. It had to be drivable entirely through an API, so provisioning could run as a step inside the existing project pipeline instead of a console task done per job. It had to reach tens of thousands of sites without per-site configuration. It had to give outside parties credentialed access scoped to their own project, plus a way in for the one-off sender who will never hold an account. And it had to take access away at project close as automatically as it granted it.

“ideally one that’s connected to SharePoint, so we’re not duplicating data, not moving data up and down”

Provisioning Files.com From the Same Script That Builds the Project

When a job is created in the firm’s ERP, existing Graph API and PnP PowerShell scripts provision the project’s SharePoint site. The enterprise applications team extended that same pipeline to call the Files.com REST API and CLI in the same run: mount the new site into Files.com, create the folders and external user accounts, and apply the permissions.

The mount is what keeps SharePoint the system of record. Using Files.com Remote Server Mounts, each project site appears as a Files.com folder while the files stay in SharePoint, so a file a client uploads through Files.com lands directly in that project’s SharePoint folder. And because every project site follows one naming convention keyed to the job number, a single system-level Entra ID connection to the SharePoint tenant covers the entire estate. Mounting the next project is a path under a connection that already exists, not a new credential to configure. That is the property that makes 150 a day survivable.

Access follows the ERP. The permissions applied at provisioning inherit from job assignment, so a person who logs in sees the projects assigned to them and nothing else, and an outside party’s credentials reach only the folders for their job. Counterparties with an ongoing role get a credentialed portal account; for the one-off sender, Files.com share links and inboxes take a file in with no account and place it in the correct project folder.

The lifecycle now runs in both directions. When a project closes, the same automation removes its external users, so access ends when the job does instead of accumulating.

The Share Path Became a Property of the Project

With the Files.com provisioning live inside the project pipeline, Rimkus replaced a per-project setup task with a pattern that applies itself.

• Every new project carries its own external exchange path from the moment it exists. The 15-minute requirement is met by construction, at 150 new projects a day, with no request to IT in between.
• Client files arrive straight into the project’s SharePoint folder, whether they come through a credentialed account, a share link, or an inbox. Nobody selects files, stages them on an SFTP server, and regenerates a link when it expires.
• Access is revoked by the same automation that granted it, so a closed project stops carrying live external accounts instead of leaving them behind for someone to remember.
• Every business unit runs the same pattern. The firm-wide standard exists because the pipeline enforces it, not because a policy asks for it.

The compounding result is what the next project costs. One connection and one naming convention reach the whole estate, so each new site is mounted by path the moment the script runs, without adding per-site connection or credential configuration as the count climbs past 20,000 active sites. External file exchange now scales at whatever rate Rimkus opens jobs, which is the rate the business grows.

The share path stopped being something IT does for a project and became something a project has.