An Expiry Clock Keeps a Canadian Municipality’s Files.com Exchange From Becoming a Repository

A Canadian municipal government runs more of itself than most municipalities. Its departments support city hall, parks, a police force, a public library, and a municipal utility. A city that builds and operates its own infrastructure is permanently in business with outside firms. The Engineering department alone exchanges CAD and PDF drawing sets with contractors, consultants, and mechanical engineers in both directions, at sizes running to tens of gigabytes per share.

Email was not built for that work: drawing sets of that size fail on mail servers. The city wanted a browser-based exchange scoped per project, where every temporary file expires on a schedule and genuine city records move into OpenText. Files.com became that exchange for Engineering.

Drawing Sets Too Big for Email

Even the files that squeezed through email clogged project managers’ inboxes. Sharing a drawing set with a consultant meant uploading, inviting, re-inviting for the revised version, and then chasing staff to download the final copy into the city’s records system.

The users could not be asked to carry the policy themselves: they were non-technical staff across every department, plus outside firms that could not be told to install a client.

The city’s records rules added a constraint most businesses never face. Anything that was a true city record belonged in OpenText, the city’s records management system, not on any third-party platform. Whatever the sharing platform was going to be, it was transient by design.

What the Exchange Layer Had to Enforce

On a platform where nothing expires, a transfer service becomes a repository one upload at a time. The city wanted an exchange layer where transience is enforced by the platform.

It had to work in a browser with nothing to install, for staff and outsiders alike. It had to scope every external party to their own project, expire files by default while leaving a clean path for genuine records into OpenText, and let Engineering provision access without queueing behind IT. As a Canadian municipal government, the city also required its data to be hosted in a Canadian region.

The city selected Files.com to be that exchange layer.

A Files.com Site in Canada Where Expiry Is the Default

The city stood up a Files.com site under its own domain, hosted in Files.com’s Canadian region, with access geo-restricted to Canada. The residency requirement was met by the platform itself, on day one.

Access required only a browser. Staff worked through the Files.com web interface with nothing to install. Outside firms received password-protected share links that expired, uploaded into Files.com inboxes, or received scoped accounts against a project folder. A consultant with a drawing set of tens of gigabytes could click a link on the city’s own domain and upload or download, with no account creation and no call to IT.

The city scoped access by project. Groups and folder-level permissions governed who could reach what, so an external account or link reached its project folder and nothing else. Files.com’s delegated administration pushed provisioning into Engineering: staff there acted as group and folder admins for their project areas, adding users and granting access directly.

A default file expiration applied across the site, so anything shared for review disappeared on schedule. Staff triaged what arrived: a file that was a genuine city record was downloaded into OpenText, and everything else rode out the retention clock. The line between a transfer platform and a records repository is a folder setting.

The rollout to people began with Engineering: three projects to validate the folder structure and permissions, one-on-one training, and a guidance document the department wrote itself.

What Changed Once Engineering Went Live

With the Engineering rollout in production, the city established a repeatable exchange pattern: files move through one governed site, records land in OpenText, and everything else expires.

• Drawing sets of up to tens of gigabytes now move between Engineering and its outside firms in both directions through the browser, with nothing for the contractor to install and no inbox involved.
• Storage is controlled by policy. City records are pulled into OpenText, while temporary files disappear on schedule.
• For the Engineering projects, sharing runs on one branded site, where every account and share link is scoped to its project.

The pattern Engineering validated could extend to other departments: a departmental group, delegated admins, per-project folders, and the same default retention, with nothing re-architected for the next rollout.

Governance That Runs on Defaults

Today, an engineer sharing a drawing set opens a browser, and the consultant on the other end clicks a link. What used to begin with a failed email and end with someone chasing a download now starts and finishes on one site. When the review is over, the files are gone on schedule.

The city put its policy into the platform. Staff still identify genuine city records and move them into OpenText, and everything else carries a clock. A sharing platform stays a sharing platform only if transience is enforced, and the city enforces it in Files.com.