Why do email and consumer file-sharing tools struggle with engineering files?

They were built for different requirements — general-purpose sharing of files well under the size of a structural model, coordination file or scan dataset, with no need for native format preview, version control tied to a revision, or an audit trail of who received and opened a file. Structural and BIM files need all four by default.

What is the biggest risk in an ungoverned file exchange process?

Version confusion — a re-upload creating a new link or file name with nothing in the exchange itself stating which one is current. On engineering work that risk is not cosmetic: a party working from a superseded revision can fabricate or build to the wrong detail.

What should a revision-controlled file exchange include?

Enough headroom on file size that a full model or drawing set is a normal transfer, native support for the formats the discipline works in, version control tied to the transfer itself, an audit trail of who received and opened each file, and a route back into the project's controlled environment rather than a side channel.

Who should own the transmittal register on a project?

A single named point of issue for each package, so a drawing does not go out through several people's inboxes under several different naming conventions. The register — what was sent, to whom, in which revision, on what date — should tie back to the same source the RFI log and check record reference.

ARTICLE

What Breaks When Large Model and Drawing Files Change Hands

Structural models, coordination files and full drawing sets routinely outgrow the tools most teams reach for first. Here is what actually breaks when a large file changes hands, and what a reliable exchange process needs instead.

14 August 2026 6 min read

Why large file exchange keeps breaking on AEC projects

Every structural engineering project eventually needs to move a file too large for the tool someone reached for first. A coordination model, a full drawing set, or a batch of laser-scan point clouds routinely runs past what an email attachment or a consumer-grade sharing link was built to carry, and the workaround — split it into parts, zip it, send a second email with the missing sheet — is where version confusion and missed revisions usually start.

This is not a niche problem. Detailing, BIM coordination and fabrication data all depend on the recipient having the current file, in a format they can actually open and check, with a record of who sent what and when. When the exchange mechanism cannot be trusted, that trust gets rebuilt manually — a phone call to confirm which version is live, a duplicate upload sent just in case — and the manual rebuild is where a project's schedule quietly leaks time.

What actually breaks

A handful of failure patterns recur across almost every project that relies on general-purpose file sharing for engineering work.

Size limits. Structural BIM models, point clouds from a scan, and full drawing sets routinely exceed the caps that consumer and even many business-grade sharing tools were designed around, forcing files to be split in ways that break the package apart.
Expiring links. A shared link that lapses after a few days works fine for a one-off exchange and badly for a review cycle that runs longer than expected, which is most of them.
No native preview. A recipient who cannot open a model or drawing format without installing specialist software either delays the review or approves something they have not actually looked at.
No version control. Every re-upload creates a new link or a new file name, and nothing in the exchange itself says which one is current.
No audit trail. A last-modified timestamp is not evidence of who downloaded what, when, or whether the right person ever actually received it.

An infographic listing six shortcomings of general-purpose file sharing on engineering work: links that lapse after three days, size caps that cannot carry folders or files past a couple of gigabytes, no way to track which revision is which, no log of who viewed or downloaded a file, no markup or comment tools so feedback scatters across email, and no connection to a common data environment, forcing manual re-uploads — The same gaps recur: size, expiry, revision, audit trail, review tools, and the route back into the project's own environment.

Why general-purpose tools fall short for engineering files

None of this is a failure of the tools themselves. A consumer file-sharing service is built for exactly what most of its users need, which is getting a large photo or video to a friend before a link quietly expires. The mismatch is that structural and civil engineering work has different requirements almost by default: files large enough to strain most free tiers, formats that need a specialist viewer to review properly, and a safety context where knowing exactly which revision was issued to whom is not optional. Confidentiality adds another layer particular to this sector: a structural model or fabrication drawing can be commercially sensitive or contractually restricted, and a sharing tool with no meaningful access control beyond a guessable link does not treat that risk as seriously as the underlying data usually deserves.

General-purpose cloud storage closes some of these gaps — higher size limits, longer-lived links, some access control — but it was still not built around a drawing register or a revision-controlled deliverable. It stores a file. It does not know that the file is Revision C of a connection detail that superseded Revision B two days ago, or that three other drawings reference the value that just changed.

What a reliable exchange process actually needs

A file exchange process built for engineering work needs to do a specific, fairly short list of things well.

Headroom on size, so a full coordination model or scan dataset is a normal transfer rather than an exception that needs a workaround.
Native format support for the formats the discipline actually works in, so a recipient can preview and check a model or drawing without installing separate software first.
Version control tied to the transfer, so a new upload is recorded as a revision of something, not a disconnected new file competing with the old one.
An audit trail that records who received, opened and downloaded a file and when, not just when it was last modified.
Access that expires deliberately, on a timeline the project sets, rather than on a default the sharing tool picked.
A route back into the project's controlled environment, so the exchange is a step inside the record, not a side channel reconciled with it later.

This is a process question, not just a tooling one

The tool matters less than the discipline wrapped around it. A transmittal register — what was sent, to whom, in which revision, on what date — turns an argument about which file is current into a five-second lookup. A single named point of issue for each package means a drawing does not go out through three different people's inboxes under three different naming conventions. The same discipline applies when a file crosses from one discipline to another — structural to architectural, or engineering to fabrication — since a handoff is exactly the point at which an assumption about which version is current is most likely to be wrong.

File naming and revision conventions agreed at the start of a project sound like a formality until a fourth party joins the distribution list and starts naming files their own way. Every large-file exchange should tie back to the same source the RFI log and the check record reference — if the file that moved between two parties is not the same file the project's register says is current, the register has already stopped being the single source of truth it was meant to be.

Getting file exchange right on your next project

None of this requires exotic technology. It requires treating file exchange as part of the controlled process a project already runs — the same rigour applied to a revision register and a check record — rather than as a logistics problem solved once and left alone. A team that can say, without checking, which file is current, who has it, and when it was sent has usually already solved the harder problems the exchange mechanism only exposes.

Before the next large model or drawing set needs to move between offices, it is worth testing the exchange process the same way the drawings themselves get tested: ask what happens when a file is too big, who can see it was opened, and what stops two people working from two different revisions at once. If those questions do not have a confident answer, the tool is not the problem yet — the process around it is.