TC Transcontinental’s Mirazed Plant Builds Customer Identity Into Pre-Press Intake With Files.com

TC Transcontinental operates printing, packaging, and media businesses across multiple business units. Its printing and premedia operations carry retail and marketing work from creative through to press.

Every print job starts life as a file. A print plant’s raw material is the customer’s artwork, and before any press runs, that artwork has to cross from the customer’s systems into the plant’s pre-press pipeline to be checked and proofed. At the Mirazed plant, a commercial printing operation acquired as part of two Groupe Canva business units in 2025, Files.com now gives each upload a customer identity and hands it to the plant’s on-premises automation. For years, that crossing was also where production waited for a person.

Every Inbound File Needed a Person to Say Whose It Was

The inherited file-transfer estate included a plain FTP server used regularly by 400 to 500 external accounts. At Mirazed, a graphics file arrived carrying its filename and no more: no record of which customer account it belonged to, no signal to production that it existed, nothing for automation to act on.

So the work in front of pre-press was human work. Someone had to identify each inbound file against a customer, route it into the pipeline, and let the customer service representative responsible for that account know the files had been received. Nothing acknowledged the customer automatically, and inbound files had no automated route from the customer into the pre-press pipeline at all.

Two facts made that hard to engineer away. The information that identifies a file is not entirely the uploader’s to give: a customer knows their own company name, but not which rep inside the plant owns their account, and that mapping lives in the plant’s records. And the automation that runs pre-press lives on-premises, watching folders on the plant’s own storage, while the customers sit on the other side of the internet. Any intake had to close both gaps at once.

A Safer Protocol Would Not Have Fixed It

The broader business was already moving to retire plain FTP. A service carrying hundreds of external accounts over an unencrypted protocol was a security problem in its own right. But swapping the protocol would only have secured the transport: a file delivered over an encrypted channel arrives exactly as anonymous as one delivered over FTP, and the manual gate in front of Mirazed’s pre-press workflow would have survived the upgrade untouched.

What pre-press needed was an intake rebuilt around identity and events. A place where a client could log in and send a file. Uploads that arrived already attributed to a customer account, carrying the company name and responsible rep that the uploader could never supply, so files could be identified and acknowledged automatically. And a landing zone the on-premises automation engine could watch.

The plant chose Files.com to be that intake layer.

From Customer Upload to Pre-Press, With Nobody in Between

External print customers upload graphics into client-specific folders on the plant’s Files.com site. The folder itself carries the identity: where a file lands says which customer sent it, so the attribution that used to be worked out by hand is now structural.

From there, the on-premises Files.com Agent securely syncs the intake folders to a NAS landing zone inside the plant’s network without exposing on-premises systems to inbound internet traffic. The Switch workflow automation platform monitors that landing zone and launches the production workflow whenever a new file arrives, with Files.com webhooks supporting the same automated handoff.

The pipeline runs in both directions. Once pre-press processes a job, a low-resolution pre-flight image—the proof that shows the customer how their job will print—is uploaded to Files.com and goes out with the request for approval. The platform that brings the artwork in carries the proof back out.

Production Now Starts Itself

With the Files.com intake in production, the plant replaced a manual identification-and-routing gate in front of pre-press with a pipeline that starts on its own.

• Every customer upload triggers the pre-press workflow on arrival. Nobody identifies the file, routes it, or hands it to production; Switch fires as soon as the sync delivers it.
• Files arrive attributed. A file lands in its customer’s folder, so the plant knows whose job it is without a person working it out.
• The approval loop runs on the same platform. Artwork comes in and pre-flight proofs go back out through one path, and the customer approves from what Files.com delivered.

The pattern also compounds. Taking on another print customer means another folder in the same tree: the same Agent sync carries it, and the same trigger fires. The intake was built once, and each additional customer can inherit it.

The Front Door of the Production Line

The job in front of the job — identify the file, route it, tell the rep — is gone.

Files.com did not end up adjacent to the plant’s production system. It is the intake stage of it: the point where a customer’s upload stops being a delivery someone has to sort and becomes the event that starts the job. That is the difference between an upload portal and a production system. A portal that only accepts files leaves everything after arrival to people. When the upload carries its customer’s identity and fires an event, the automation can act on every file with nobody in between.