A Higher-Education Analytics Firm Replaces Dropbox With Files.com—and Automatically Expires Dormant Client Access

A higher-education analytics firm helps colleges and universities decide which academic programs to start, stop, or grow. Its platform pairs national market data on student demand, employment, and competition with each institution's own academic economics: revenue, cost, and margin, calculated down to the course-section level. Institutions ranging from small trade schools to statewide public systems rely on it for those decisions.

The market data the firm assembles itself. The economics side works only one way: each client institution hands over its own internal data, from enrollment to financials to program performance, so the firm's analysts can build the picture. Every engagement begins with a college sending the firm some of its most sensitive institutional data, and ends with the firm sending back deliverables too large for email.

Clients That Send Files for a Few Weeks, Then Go Dormant

That exchange has an unusual shape. The firm's data submitters are not a workforce. A university sends files for a bounded stretch of an engagement and then goes quiet, exchanging files only occasionally. Across its client institutions, that produces a continuously rolling population of external accounts: essential one month, dormant the next.

Dropbox held the firm's file estate. To govern that rolling population, the firm needed client access tied to the Okta directory that ran its other systems, a per-client wall between one institution's submissions and the next, and a rule that retires a submitter's account when its engagement ends.

The problem carried a proof dimension too. The firm's clients are universities, and universities run security reviews on any vendor that will hold their data. The promise the firm makes to data-providing institutions had to be demonstrable: isolated per client, governed by identity, backed by audit evidence.

The firm needed its file exchange to run on the same rules as the rest of its estate. Whatever replaced Dropbox had to give each institution its own isolated space authenticated through Okta, retire dormant submitter accounts on a schedule, return deliverables too large for email, keep the data on storage the firm controls, and let analysts keep working the same files day to day. The firm selected Files.com as that front door.

A Permissioned Front Door Over the Firm's Own Azure Storage

Files.com became the permission and protocol layer in front of storage the firm already owns. Using Remote Server Mounts, Files.com presents Azure Blob and Azure Files as ordinary folders, so the corpus lives in the firm's own Azure tenant while every user, permission, and transfer passes through Files.com. The existing Dropbox corpus moved across in a one-way sync into Azure Blob with its folder structure intact, and the storage has not had to move since.

Identity comes from the directory the firm already runs. SAML single sign-on and SCIM provisioning tie Files.com to Okta, and client institutions authenticate through Okta into their own folders, with granular folder permissions keeping each client's submissions walled off from every other client's. Analysts pick the files up through the Files.com Desktop App, which is their day-to-day working interface onto the same Azure-backed folders.

The lifecycle got a rule. The firm built a role in Files.com that automatically disables any user inactive for a set period, so the rolling population of one-time submitters prunes itself as engagements end. Outbound, deliverables that outgrow email go back to clients as Share Links on the firm's own domain, downloadable in a browser with no account or software on the client's side.

New Clients Onboard as They Arrive, and Dormant Access Expires on a Clock

With Files.com in production, the firm replaced Dropbox with a client exchange that runs on the same identity and lifecycle rules as everything else it operates.

• Every new client institution is onboarded onto Files.com as it arrives. Adding one means a folder and Okta-governed access, so onboarding another institution adds no new file-exchange project.
• Nobody prunes external accounts by hand. A submitter who finishes an engagement and goes quiet is disabled automatically after a set period of inactivity, so the population of external accounts tracks the population of active engagements.
• Deliverables too large for email go out by Share Link on the firm's own domain, and the client only needs a browser to receive them.
• The security promise now travels with evidence. Files.com's SOC 2 Type II reporting goes directly into clients' own security reviews when institutions vet how their data will be handled.

The Engagement Ends, and the Access Ends With It

That is the lesson the deployment carries for any firm taking in confidential data from a rotating cast of client organizations. A rolling population of short-lived external submitters is governed by a rule, and the rule runs on its own.