How Email Attachments Should Be Stored in a Legal DMS

The same contract draft exists in five inboxes as five separate attachments. Nobody knows which version is current. And “the one with the redline from opposing counsel” turns into a search across Outlook, a shared drive, and someone’s desktop that still produces the wrong result.

It’s the attachment that creates the mess.

Most firms that file email into a DMS don’t have a clear rule for what happens to it at the point of filing. This article gives you one.

Attachments carry the most critical information in your matter files: contracts, briefs, agreements, court filings, settlement terms. And they’re the single most common source of version confusion, duplication, and search failure.

Most firms manage email fine, but nobody makes a deliberate decision about the attachment at the point of filing. Attorneys handle it differently every time:

Without a clear framework, every attorney develops a different habit, and the DMS can’t answer a basic question: which version of this document is current?

Every email attachment falls into one of two categories. The right handling depends on which one you’re looking at.

Court notifications, news articles, reference materials, FYI documents, background research. These don’t need their own DMS entry. They stay with the email as context in the matter record.

If the attachment exists to support the email and won’t be revised or referenced independently, filing it with the email is the right call.

Contracts, briefs, agreements, and anything that will be revised or referenced on its own should be filed as standalone DMS entries with version control and stay attached to the filing email for context.

The email preserves when and how the document arrived, while the standalone entry becomes the canonical working version. Both serve the matter record, but they serve it differently.

This is the most damaging consequence of poor attachment handling, and it shows up in every firm that hasn’t built explicit rules around working documents.

Picture a purchase agreement under negotiation. The first draft arrives as an email attachment from opposing counsel. Your attorney saves it locally, makes changes, and sends it back.

Opposing counsel does the same. The client’s business advisor sends a marked-up copy to both parties. Six weeks later, your firm has files named Purchase_Agreement_v2, Purchase_Agreement_FINAL, Purchase_Agreement_FINAL_revisions, and Purchase_Agreement_FINAL_actually_final scattered across four inboxes and two desktops.

Nobody knows which version was executed.

Using the wrong version of a contract during a closing is a professional liability. When the working document lives as an email attachment rather than a single canonical DMS entry, you’ve built a system that makes version confusion almost inevitable.

Check-in/check-out and version history are the structural answer to the proliferation problem.

When a new version of a document arrives as an email attachment, it should be checked in as a new version of the existing DMS entry, not saved as a new file. The email carrying that attachment gets filed to the matter as context. The DMS entry gains a new version in its history.

The result is a clean, searchable version trail:

A firm with strong version control practices can reconstruct the full negotiation history of a contract from a single document entry instead of digging through six inboxes looking for “the one from the week of the 14th.”

The deduplication scenario comes up constantly in legal practice: the same document arrives from your client, opposing counsel, and a mediator in the same week.

Don’t create three separate standalone documents. Maintain one canonical working document entry in the DMS. File each email with its attached copy to the matter record as context.

They show who sent what, when, and with what cover language.

The rule: Three emails, one canonical entry. The emails are the audit trail; the DMS entry is the working version.

Keeping those purposes separate prevents the exact kind of clutter that makes the DMS unreliable.

A scanned PDF arriving as an email attachment is invisible to full-text search unless your DMS applies OCR when it’s filed. That’s a filing-stage problem, not a search-stage problem.

If OCR doesn’t happen when the attachment enters the matter record, you’ve created a document that exists in the DMS but can’t be found by content. The attorney knows the scanned agreement is somewhere in the matter, but the search bar can’t find it.

Common gap: Many firms discover their OCR problem only when they can’t find a scanned document they filed months ago. By then, the gap has been building across every scanned attachment in the system.

A DMS that applies automatic OCR at the point of filing closes this gap before it becomes a retrieval failure down the line.

The framework above comes down to three questions you can apply in five seconds every time you file an email with an attachment.

1. Is this a working document?

→ File as a standalone DMS entry with version control. Keep it with the email too.

2. Is this a new version of something already in the DMS?

→ Check it in as a new version of the existing document. File the email as context.

3. Is it informational only?

→ File it with the email. No standalone entry needed.

That’s it. Contracts, briefs, and agreements trigger question one. Revised drafts from opposing counsel trigger question two.

Court notifications, reference materials, and FYI documents trigger question three.

If you’re building a filing standard for your team, this checklist is the reference card.

LexWorkplace is a cloud-based document management system built for law firms, and its email management features map directly to the framework above.

The framework in this article works with any DMS that supports version control and email filing. LexWorkplace is built to make the “file as a standalone document” path fast enough that attorneys can make the right decision at the point of receipt without it feeling like extra work.

The firms that handle email attachments well don’t do it because they have better tools. They do it because someone built an explicit rule and made it easy to follow.

The framework here is simple enough to apply in five seconds at the point of filing. The version proliferation problems it prevents take hours to untangle after the fact. The decision is easier to make now than to reconstruct later.