VelocityEHS Took the Human Out of Customer Data Intake by Building Files.com Into Its Product

VelocityEHS makes cloud software for environment, health, safety, and sustainability management.

Several of its programs run on customer employee data. An internal team VelocityEHS calls the Center of Excellence delivers an HRIS-integrated capability: customers supply datasets about their own workforce, and the VelocityEHS application processes them. That means the product only works if files keep crossing a boundary, out of HR systems VelocityEHS does not control and into the AWS infrastructure where its application runs.

Every Dataset Passed Through a Person First

For years, that crossing was made by hand. Customers delivered their datasets to an on-premise SFTP server. Someone at VelocityEHS downloaded the files, assessed them, and re-uploaded them into the application.

Onboarding was heavier still. Early in a new customer's onboarding, large datasets move back and forth, in batches of 500-plus files at a time. Those, too, were downloaded and re-uploaded by hand into SharePoint, where the onboarding work happens.

The cost was not any single transfer. It was that intake capacity equaled people. Every upload waited on a person, every new customer added handling work instead of reusing a pattern, and these were employee datasets from customers' HR systems, handled by hand as a routine step of doing business.

Why a Person Stood in the Middle

The manual step existed for a reason. The application's storage is Amazon S3 inside VelocityEHS's own AWS environment, and S3 speaks none of the protocols a customer or an HRIS export can use. Handing outside parties a path into backend buckets was never an option, and each customer's data had to stay strictly separate from every other customer's. So a person stood in the gap: the only bridge between an external transfer surface and the application's storage.

That held for a limited customer base. It could not hold as the Center of Excellence expanded, because every new customer on a manual path meant more handling. VelocityEHS needed an intake layer that gave every customer its own login and folder, spoke SFTP so an HRIS system could feed it directly, kept customers fenced off from one another, and delivered every file straight into VelocityEHS's own S3 with no middle copy and no middle person.

VelocityEHS built that layer on Files.com. The company had already retired its on-premise FTP servers onto the platform; this time it put Files.com inside the product itself.

The Folder Is the Bucket

Each Center of Excellence customer gets a folder and a login under VelocityEHS's own domain. During onboarding and in steady state, they sign in and upload their datasets: CSV and JSON files, plus supporting PDFs.

Behind those folders sit Files.com Remote Server Mounts pointed at VelocityEHS's S3. The folder is not a landing zone that forwards files somewhere else. It is the bucket, presented through Files.com. The moment an upload completes, the file is in the application's storage, and the application processes it. Storage of record stays in VelocityEHS's AWS; Files.com is the transfer and control layer in front of it.

Customer HRIS systems connect the same way. An HR platform that can export over SFTP points its integration at Files.com and delivers employee data into the same per-customer structure, so the feed runs from the customer's HR system into the VelocityEHS application with nothing manual in between.

The onboarding exchange runs on the same platform. Instead of a person downloading a 500-file batch and re-uploading it into SharePoint, a Files.com Sync moves each batch between Files.com and SharePoint on its own.

The estate this runs on is substantial: nearly 30 remote server connections, most of them S3 mounts, driving more than 280,000 API transactions against Files.com every day.

From a Person Per Upload to a Pattern Per Customer

With the integration in production, VelocityEHS replaced per-customer manual handling with a repeatable intake pattern built into the product.

• Human handling is gone from customer data intake. A customer uploads, and the file goes directly into the application. Nobody at VelocityEHS downloads, assesses, or re-uploads it.
• Onboarding file exchange runs itself. The 500-plus-file batches that used to be moved by hand now flow through a Files.com Sync into SharePoint.
• Intake capacity stopped scaling with headcount. Adding a customer now means a folder, a login, and a mount rather than another person's workload.
• The on-premise SFTP server that fronted intake is retired, along with the rest of the on-premise FTP estate it belonged to.

File Transfer as Part of the Product

VelocityEHS did not deploy Files.com beside its product as internal plumbing. It made Files.com a component of the product: the layer that takes customer data in and lands it in the application's own storage, with every customer kept separate along the way. A SaaS company whose product runs on customer data does not have to build and staff that layer itself.