SAI360 Replaced Manual FTP Handoffs With 300 Terraform-Provisioned Files.com Inboxes

SAI360 makes governance, risk and compliance software for organizations that answer to regulators: hospitals, banks, government bodies, defense contractors. It operates across the Americas, EMEA and APAC. Alongside the GRC platform sits a learning business that is substantial in its own right, an ethics-and-compliance training operation delivering courses in multiple languages.

That learning business runs on client data. Clients have to get data files into SAI360's performance dashboard, and the people sending them are the people who buy compliance training: HR and compliance staff, business users of SAI360's software, not engineers. Files that must move, sent by people who will never open an SFTP client. That is the condition the rest of this story follows from. The answer would pair browser-based uploads with automatic attribution and routing, using roughly 300 intake pages provisioned through Terraform.

Every Client File Ran Through an Account Manager Twice

The learning division had no formal upload system. Client file intake was an exception process, rebuilt by hand for every client. When a client needed to submit data, an Account Manager stood up FTP access for them through an internal learning-management portal and shared the credentials. When a file arrived, the same Account Manager logged into that portal, navigated to the right section, downloaded the file, and uploaded it into the performance dashboard. When the dashboard rejected it, the Account Manager interpreted the error messages and coordinated with the client on formatting. Project Managers had no direct access to content uploads at all; they waited on the implementation team to retrieve files for them.

The cost on the client side was heavier, because it landed on people who had no reason to carry it. Standing up an FTP connection meant a compliance manager filing a ticket with their own IT department before they could send SAI360 a single file.

“If we can have something that they understand, which is, oh, to get those files to SAI 360 I just click on this link and I drag and drop my files into this folder.”

Built for Senders Who Will Never Open an SFTP Client

Two facts boxed in any replacement. The senders were non-technical, so anything that required installed software, keys, or a client's IT department would reproduce the problem it was meant to remove. And the intake could not be a generic dropbox: every submission had to be attributed to the right customer account, kept separate per customer, and routed to the team responsible for it. Email and ad hoc links could deliver files. They could not deliver attribution.

Demand had also outgrown the manual chain. Ten learning clients needed the capability immediately, and SAI360 expected a large share of its 500-plus learning customers to want the same path. A process that consumed an Account Manager at both ends of every file does not survive that arithmetic.

So the fix had to be a URL a business user could operate from a browser with nothing installed; it had to capture who was sending, and for which account, before the file landed; it had to route each submission and notify the right team on its own; and it had to be reproducible by the hundreds without hand configuration. SAI360 selected Files.com to be that intake layer.

One Inbox per Intake, Provisioned as Code

Files.com became the learning division's standing front door for client files: one branded upload page per intake, each created and managed the way SAI360 manages the rest of its estate, as code.

The client's path is the whole of what the client sees. They open a URL, fill in a short registration form (name, email, company, customer account number, and file type) and drag their files onto the page. There is no account to create, nothing to install, no keys to exchange, and nothing for their IT department to configure.

The routing happens on arrival. Files.com uses the form answers to build the folder path, so each submission lands in a subfolder created automatically for that account number and use case, attributed and segregated before anyone touches it. An email notification goes to a distribution group the moment a file lands. The team pulls the file through the Files.com desktop app and imports it into the performance dashboard; nobody logs into a portal to find out whether anything came in.

And the pattern reproduces. SAI360 provisioned roughly 300 inboxes through the Files.com Terraform provider. Those inboxes represented distinct intake paths, not 300 individual clients; each could sort submissions by customer account number and use case. Defined and version-controlled like the rest of SAI360's infrastructure, adding an intake is an entry in a plan, not a provisioning task.

Intake with Nobody in the Middle

With the inboxes in production, SAI360 replaced an exception process built around hand-provisioned FTP with a standing self-service intake pattern. What that changed:

• Per-client provisioning is gone. A learning client can send its first file the day it needs to, with no FTP account built for it and no credentials shared.
• Nobody ferries files. Submissions arrive already sorted by account number and use case and announce themselves to the team, and the download-and-re-upload loop through the old portal no longer exists.
• Clients stopped needing their own IT. The entire path is a browser page, and a compliance manager who has never touched SFTP can complete it alone.
• Intake scales ahead of demand. Growing from the first ten clients toward the hundreds expected to want the capability means stamping out more inboxes from code, not designing more workflows.

The immediate saving is the Account Manager hours that used to go into every file. The compounding one is what each new client now costs: nothing that resembles a project.

Client file intake stopped being a service that Account Managers performed one client at a time and became infrastructure that Files.com runs for all of them. SAI360's clients never got more technical. The intake stopped requiring them to be.