Cincinnati Public Schools Replaced Fax With a Files.com Exchange Layer for Student Records and Sealed Bids

Cincinnati Public Schools is a public K–12 district serving the city of Cincinnati across more than 60 schools.

A district that size runs on documents moving among its schools, systems, and outside organizations. Student records, transcripts, and withdrawal documents move to education platforms the district works with, including PowerSchool, Naviance, Savvas, Focus, and Qualtrics, as well as to banks and a major regional children’s hospital. District IT moves backend data files between the central office and individual schools. Procurement brings sealed bids in from outside vendors.

Student-record traffic contains protected personal information. Procurement submissions carry a different confidentiality requirement: each sealed bid must remain hidden from competing vendors. The hardest file exchange problem was the steady traffic of protected records and confidential bids crossing the district boundary in both directions. Cincinnati Public Schools replaced fax with Files.com, creating one centrally managed exchange layer for automated SFTP transfers, browser-based exchanges, and sealed bid intake.

Protected Records Were Moving by Fax

That traffic went by fax. Student records, RFP documents, and backend IT data files moved between district IT, individual schools, and outside parties through a channel built for pages rather than system-ready files.

The cost showed up in the destination. A fax can put a page in front of a person. It cannot deliver a data file into an education platform, and many of the places district records had to land were systems, not people. Anything bound for a platform rather than a desk meant manual handling on both ends of the exchange.

Procurement carried its own version of the problem. Sealed bidding requires that no vendor see another vendor’s submission, and paper arriving at a machine keeps competing bids apart only as well as the people handling it do.

The Replacement Had to Serve Three Kinds of Counterparty

The district exchanged files with national software vendors, banks, a hospital, individual schools, and vendors with a single bid to submit. Any replacement had to cover that same range without forcing every counterparty into a workflow they could not use.

That set the requirements. Software platforms and banks needed automated, machine-to-machine transfer over a standard protocol. One-off external parties needed a way to send and receive files in a browser, with no account and nothing to install. RFP submitters needed inbound channels sealed from every other submitter. And whatever replaced fax had to support the district’s scheduled overnight transfer processes.

Cincinnati Public Schools selected Files.com to be that single exchange layer.

SFTP Feeds, Browser Links, and Sealed Receive Folders on One Platform

District IT configured Files.com as the exchange layer for all three kinds of counterparty at once.

For systems, records moved over SFTP. Student records, transcripts, and withdrawal documents transferred to the district’s education platforms, banking counterparties, and hospital exchange.

For people, staff administered Files.com Share Links through the web interface. An outside party opened a link in a browser and did exactly what the link permitted.

For sealed bids, the district used receive folders: upload-only channels where each RFP submitter could add files but no submitter could see what anyone else had sent. Confidentiality between competing bidders was enforced by the platform itself, not by whoever collected the paper.

The district scheduled its file processes overnight, so records moved on the calendar the district set rather than on someone’s working hours.

What Moves Electronically Now

With the Files.com workflows in production, every flow the district formerly faxed now moves electronically. Scheduled processes move records overnight as files destination systems can consume, without paper handling. One-off counterparties use browser links rather than being added to district transfer workflows, while receive folders preserve separation among bidders.

The compounding result is that the district no longer builds a new mechanism per counterparty. A new platform feed is a folder and a credential. A new bidder is a link. Whatever the next exchange looks like, one of the three patterns already fits it.

From a Fax Machine to an Exchange Layer

Today, Files.com carries those exchanges as one system administered by district IT.

The lesson reaches past this district. Retiring fax did not mean forcing every counterparty onto one workflow. The district’s counterparties are as different as a national software platform and a vendor with a single bid, and Files.com gives each of them its own way in or out while the district administers everything as one platform.