Clio document automation, and where it stops
Document automation in Clio is a merge: you build a template in Word (or another supported format), drop in tags that name a field on the matter or the contact, and Clio fills those tags with that matter's data to produce a finished document saved in the matter. That's genuinely useful plumbing for engagement letters, retainers, standard notices, and anything else your firm re-types the same way every week. It's also narrower than the phrase "document automation" suggests — field substitution isn't conditional drafting, and a template library quietly rots if nobody owns it. This guide covers how templates and merge fields are built, where the generated file lands, the limits firms actually hit, and the question this topic usually leaves unanswered: what happens to documents your firm generates somewhere other than Clio. Clio's document features change over time, so confirm current specifics in Clio's help center.
A merge, not a drafting assistant
Document automation in Clio is a mail merge with a matter behind it. You write the document once, mark the places where the details change — client name, address, matter description, today's date — with tags that name the field, and store the result as a template. Generate from that template against a matter and Clio fills each tag with that matter's data. What comes out is a finished document saved in the matter, not a draft you have to reconcile against a client record.
The gain is narrower than the phrase suggests, and clearer for it. It doesn't write your argument, choose your clauses, or know that this client is an LLC. It removes re-keying — and, more importantly, it removes the proofreading pass that exists only because a human re-keyed something. The classic failure it prevents is the retainer that goes out with the previous client's name in the third paragraph, which no amount of care fully eliminates when the document is produced by copying last month's version.
The documents worth the setup are the ones your firm produces repeatedly with the same structure and different names on them: engagement letters, retainer agreements, standard client notices, fee disclosures, routine correspondence, closing checklists. A document you write once isn't a template candidate, however long it took. The break-even is roughly "will we produce this shape again this quarter" — and firms usually find that a handful of templates covers most of the re-typing. The long tail never repays it.
Templates, merge fields, and the tags that break
The template is an ordinary document, not a proprietary object. In practice that means a Word file — .docx — because that's where the document already lived and where the formatting is easiest to control. The point either way is that your letterhead, styles, numbering, and spacing come along unchanged: you're annotating a document you already have, not rebuilding it in a template editor. Clio lists the template formats it currently supports in its help center; check there before standardizing on anything else.
The merge fields come from Clio, not from your memory. Clio publishes the list of standard merge fields in the app: the documented route is the Settings panel, then Documents in the System column, and the list is also reachable from the View Merge Fields link when you add a document template. The tags read as a dotted path naming the record and the attribute, wrapped in double angle brackets — a client's name is <<Matter.Client.Name>>, and a matter with several clients takes <<Matter.AllClients.Names>>. Copy the tag from that list rather than typing it. Paste the whole thing, delimiters included, in place of the text it replaces. Fields available to a given template depend on context — related-contact fields, for instance, appear once related contacts have been added to the matter. Confirm the current path and catalog in Clio's help center, since both move.
Three things account for most "the field came out blank" tickets. The first is a retyped or auto-corrected tag: Word is helpful about quotation marks and capitalization in ways that break an exact-match token, so paste rather than type. The second is a custom field that isn't enabled on the matter you're generating from, or on its client — a field that's switched off there has nothing to insert. The third is a symbol in a custom field's name. Clio documents a naming restriction for custom fields used in merges — keep the names alphanumeric — so an apostrophe can stop a field populating even though that field works fine everywhere else in Clio.
One formatting note that saves a rebuild: the appearance of merged text is controlled by formatting the tag itself in Word. Bold the tag; the value arrives bold. It's an obvious rule once stated and a confusing one until then, because the tag and the value it produces look nothing alike on the page.
Generated in the matter, saved in the matter
Generation starts from the record, not from the template library: you open the matter or contact, go to its Documents subtab, choose New, and create a new document from a template — picking the template, a filename, and whether you want Word, PDF, or both. (The main Documents tab offers the same route.) Clio populates the fields with that record's data and saves the result in that record's Documents area. That's the best structural property of the whole feature. The document is born filed. Nothing has to be downloaded, remembered, and uploaded later. Menu wording shifts between releases, so confirm the current steps in Clio's help center; the shape underneath is stable.
Two habits keep that advantage from eroding. First, name it on the way in: a generated document tends to inherit a template-derived name, so a folder of merged engagement letters can end up looking like a dozen copies of the same file — the naming convention should apply at generation, not as cleanup. Second, put it in the folder it belongs in, because generation isn't exempt from the folder structure every other document follows. After that it behaves like any matter document, including version history when the draft goes through rounds — with the qualification that what version history can and can't roll back depends entirely on revisions being uploaded onto the record rather than saved beside it. A workflow that generates near-identical documents from the same template invites exactly the mistake that breaks it.
Where field substitution stops being enough
Filling a blank, or changing the document's shape
Merge fields answer "what goes in this slot." Conditional assembly answers "does this clause belong in this document at all." The second is a different product category, not a setting.
Merge-field templates
Built into the practice-management system
- Does
- Inserts matter, client, and custom-field values into a fixed document.
- Best for
- Engagement letters, retainers, standard notices — same shape, different names.
- Cost
- Setup time only; it's part of the platform you already pay for.
Conditional assembly
A dedicated automation product
- Does
- Branches on the data — optional clauses, agreement of pronouns and verbs, repeating blocks, form sets.
- Best for
- Court forms, multi-party documents, practice areas built on variant paperwork.
- Cost
- A license and a build project, plus someone to maintain the logic.
Ask whether your document has branches. If it does, no amount of merge fields will get you there.
Most firms need the left column for nearly everything and the right column for one or two document families.
The hard boundary is logic. A merge field says "put this value here" and nothing else. Documents that need to change shape depending on the data — an indemnity clause that appears only for corporate clients, pronouns and verbs that agree with the party, a schedule with one repeated block per plaintiff — are asking a question substitution can't answer. Legal document automation as a category covers both jobs, which is where the confusion starts: filling blanks is the first tier and sits inside the practice-management system, while conditional assembly is a second tier that's bought separately. Clio Draft (Clio's document-automation product) is positioned there, as are third-party assembly platforms in Clio's app directory; between them they cover conditional logic, client questionnaires, and libraries of fillable court forms. These aren't competitors to the built-in feature so much as a different tier of the same job — and the honest read is that most firms need the built-in tier for nearly everything and the dedicated tier for one or two document families. Capabilities and packaging move, so confirm the current picture with the vendor.
The soft boundary is data quality. Automation inherits whatever is in the record, faithfully and at speed. A contact entered as "Bob" generates a letter addressed to Bob; an address missing a unit number generates fifty letters missing a unit number. Firms that adopt automation usually discover their contact-data hygiene about a week later. Tighten intake; don't distrust the merge. A related trap: fields that are empty produce an empty space, not an error, so a template with a rarely-populated field can generate documents with quiet holes in them. Proof the first output of every new template against a real matter before anyone sends one to a client.
The boundary nobody plans for is formatting. A template that renders perfectly with a short client name breaks a line in an unfortunate place with a long one; a table cell sized for a two-line address is wrong for a four-line one. Generated documents aren't typeset per instance — the layout is whatever the template does when the real values arrive. It's worth generating a deliberately awkward test case, a corporate client with a long legal name and a multi-line address, before a template goes into production.
Templates drift, and nothing warns you
This is the failure mode that decides whether a firm keeps getting value from automation or quietly stops trusting it. A partner revises the retainer in Word under deadline, circulates the new version, and the firm adopts it — but the stored template still carries the old fee language. The next generated retainer reintroduces text the firm abandoned six months ago, and every signal says the process worked: the merge succeeded, the fields populated, the document looks right. A template can only be wrong silently.
The remedy is ownership, not tooling. One named person owns the template library and is the only route by which a template changes — the same principle that makes a folder template hold. Review the templates your firm actually uses on a cadence: an annual pass through all of them, plus an immediate update whenever fee terms, entity names, required disclosures, or governing rules change. Anything more elaborate than that gets abandoned; anything less and the drift wins.
Two small practices make the review cheap. Keep the number of templates small — variant proliferation is the main reason a review pass gets skipped, and three well-maintained templates beat eleven that nobody has read since they were built. And make "update the template" an explicit step in the workflow whenever a form document is revised for real, so the revision and the template change happen in the same sitting rather than one of them happening never. A stored template is also a firm document like any other, which means it's subject to the same access decisions — worth a thought if a template contains fee structures not everyone should see.
The documents automation didn't generate in Clio
Generated in the matter, or filed into it later
Every finished document has to end up in the matter. Only one of these three routes gets there without a human remembering a step.
Merged in Clio
Assembled elsewhere
Executed elsewhere
Lanes II and III fail the same way: the real version lives in the tool that made it, and the matter holds a draft.
Almost every discussion of document automation stops at generation, which leaves the more common problem unaddressed. However good your templates are, a firm produces plenty of finished documents somewhere else: drafted in Word on a desktop, assembled in a dedicated automation platform, completed on a court's fillable form, executed in an e-signature tool, or received back from a counterparty. Each of those exists outside the matter until somebody puts it in, and the failure is uniform and boring: the final version stays in the tool that made it, and the matter holds a draft or nothing at all. It surfaces months later, when someone needs the signed copy and finds the unsigned one.
The routes back are well worn. A configured integration files finished documents automatically, where one exists for the tool that produced the document; a desktop sync layer makes matter storage look like a drive; downloading and uploading through the Documents area handles multiple files and whole folders, and is unglamorous enough that firms forget it works. Browser tools like Send to Case file a document straight into the matter from wherever it was produced, and the options are weighed against each other in the tools for uploading guide. Which route you choose matters far less than choosing one deliberately and naming who does it.
Born filed, or filed by hand
Merge-field automation is worth setting up for a narrow, real reason: it removes re-keying on the handful of documents your firm produces the same way every week, and the document it produces is already in the matter. The rest is discipline, not software. Templates that nobody owns go stale silently, data you never cleaned up gets reproduced faithfully at speed, and documents whose shape depends on the answers were never a merge-field job in the first place.
The through-line is the same one that governs signing, migration, and everyday filing: the matter is the system of record, and a document that isn't in it doesn't exist as far as the firm is concerned. Automation is one good way for a document to be born already in the right place. Every other way a document comes into existence needs a route back, and that route deserves as much design as the templates do. Where generated documents sit alongside everything else is covered in the broader document management guide.
What is document automation in Clio?
+It's template-plus-merge-field document generation. You create a template — an engagement letter, a retainer agreement, a standard notice — and in place of the details that change from client to client you insert merge fields, which are tags naming a piece of data Clio already holds, such as the client's name or address. When you generate a document from that template against a specific matter or contact, Clio replaces each tag with that record's value and saves the finished document. The value isn't that it drafts for you; it's that the data you already entered once stops being re-typed, which removes both the keystrokes and the proofreading pass that catches the wrong client name in paragraph three. Firms whose drafting needs outgrow field substitution generally move up to a dedicated assembly product — Clio Draft (Clio's document-automation product) or a third-party platform.
What file types can a Clio document template be?
+A template is an ordinary office document rather than a proprietary object, and in practice almost every firm template is a Word file — Word is where the underlying document was already written and where the formatting is easiest to control. The consequence of that is the useful part: your existing letterhead, styles, numbering, and paragraph formatting carry over, so you're annotating a document you already have rather than rebuilding it in a template editor. The supported template formats are listed in Clio's help center and change over time, so check the current list there before standardizing on anything else.
How do merge fields work, and what do they look like?
+A merge field is a tag you paste into the template where a piece of matter or contact data belongs — a dotted path naming the record and the attribute, wrapped in the delimiters Clio's own field list shows. Clio publishes that list of standard merge fields inside the app: open the Settings panel and select Documents in the System column, or use the View Merge Fields link shown when you add a document template. Copy the exact tag from that list into your template rather than typing it from memory. Paste the whole tag, delimiters included: a tag that has been retyped, auto-corrected, or partially reformatted by Word is the most common reason a field comes out blank or prints as literal text. Which fields are available depends on context — related-contact fields appear once related contacts have been added to the matter, for example. Treat the in-app list as the source of truth, since the catalog and the menu path both move.
Can Clio document automation pull custom fields?
+Yes, and two documented conditions cause most of the failures people report. First, a custom merge field only populates if that custom field is actually enabled on the matter you're generating from (or on the matter's client) — a field that exists in your firm's configuration but isn't turned on for this matter has nothing to insert. Second, Clio documents a naming restriction on custom fields used in merges: names should be alphanumeric, so a field name containing an apostrophe or another symbol can fail to populate. That one catches firms off guard because the field looks fine everywhere else in Clio — it's only the merge that objects. If a custom field is coming through blank, check enablement on the matter and the field's name before assuming the template is broken.
Where does the generated document get saved?
+In the Documents area of the matter or contact you generated it from — you start the generation from that record's Documents subtab (the main Documents tab works too), and the finished file is saved there rather than downloaded to your desktop and left for you to file. That matters, because the most common way a generated document goes missing is being produced somewhere else and never filed back. Once saved it's an ordinary matter document: it sits in whatever folder you put it in and can take new versions as the draft evolves. The one thing to plan for is the filename — a generated document tends to inherit a template-derived name, so a firm with a naming convention should rename at generation rather than let a folder fill with near-identical filenames.
Can Clio's built-in document automation handle conditional logic?
+Merge fields are substitution, not logic: a tag says "put this value here," and that's the whole contract. Documents that need to change shape based on the data — an optional indemnity clause that appears only for corporate clients, pronouns and verbs that agree with the party, a schedule that repeats one block per plaintiff — are asking for conditional logic, which is a different capability from filling a blank. That's the gap dedicated assembly products are sold into, Clio Draft (Clio's document-automation product) among them, alongside third-party platforms in Clio's app directory. The practical test is whether your document has branches; if it does, expect to buy or build automation on top of merge fields rather than inside them, and confirm current capabilities with the vendor before committing.
Why do our templates keep going out of date?
+Because the template and the document everyone actually uses are two different files, and only one of them gets edited under deadline. A partner marks up a retainer in Word, circulates the revised version, and the firm adopts it — but the stored template still carries last year's fee language, so the next generated document silently reintroduces the old text. Nothing in a merge-field system notices: the merge succeeded, the fields populated, the output looks right. The fix is ownership rather than tooling — one named owner for the template library, a scheduled review of the templates you actually use, and "update the template" as an explicit step whenever a form document is revised for real.
Keep going
Clio document management guide
The full picture generated documents land in — folders, categories, versions, permissions, search.
Read guide →Clio document naming conventions
What to call a generated document so a folder of merged letters stays scannable.
Read guide →Clio e-signature
The step after generation — signing, and where the executed copy ends up.
Read guide →Tools for uploading to Clio
An honest comparison of the ways files get into a matter, including documents made elsewhere.
Read guide →File what arrives from outside, in a right-click
A free Chrome extension: right-click a Gmail attachment or a download link on a court or client portal, and file it straight to the right Clio matter.
10 uploads a month free. No credit card required. See pricing