Documents and templates

Templates are the firm's own

Document generation starts from the firm's existing Word (.docx) templates, uploaded as-is, not rebuilt in a proprietary editor. Word stays the place documents are authored; the platform is where each template is mapped once so it can generate from the client record ever after. Firms group their templates into categories they control, so a growing library stays organized the way the practice thinks about it.

Tags: mapping a template

A template carries merge tags, tokens the author writes in Word wherever a value from the client record belongs. Setting a template up is a short guided flow: upload the .docx (or start from a platform-provided example, mapping included), and the platform lists every tag it found in the document. The author binds each tag to a field on the client record, choosing from a searchable catalog of the fields the platform knows, grouped the way the practice thinks about them; where a tag's name is close to a known field, the editor proposes the match and one click accepts it. Each mapping also records whether the value is required and what should print when it's blank.

A preview shows the template three ways, the tags on their own, the tags beside the document, and the document rendered with sample data, so mapping mistakes surface before a real matter depends on them. Publishing is deliberately lenient: an unmapped tag is flagged at generation time rather than blocking the publish.

Templates are versioned. Publishing creates the version new documents generate from, and every generated document stays pinned to the version it was merged against, so revising a template never silently changes documents already produced. The source .docx of any version can be downloaded, and a draft can have its source replaced with a re-edited Word file: tags that survived the edit keep their mappings, new ones ask to be mapped, and vanished ones drop away.

Sections that turn on and off

Beyond single values, a template can wrap a whole clause in a section: a block that is included as a piece or dropped as a piece, depending on the matter. The author binds each section to what decides it, one of two sources:

• A choice recorded on the matter. The attorney answers a question the firm defined (burial or cremation, say) and the matching clause renders.
• Whether a document is part of the matter. A clause like "I have attached a living will" turns on exactly when the living will is in the matter's scope of work, and off when it isn't. Nothing is asked and nobody has to remember to keep the two consistent.

Publishing requires every section to be bound, and the failure mode is safe: if a section's source is later removed (its question or document archived away), the clause drops out entirely rather than rendering the wrong one. If the facts change after a document was generated (an optional document added later, for example), the affected draft is flagged as drifted, the signal to regenerate.

Packages and the catalog

Templates describe single documents; a package describes a matter type. It bundles the documents an engagement of that type produces, the intake form it sends, and the pricing, so the firm sets up "an estate plan" or "a prenuptial" once rather than reaching for documents one at a time on every matter. Packages have their own page: see packages.

Alongside packages, the Data area of the console (open to firm admins and attorneys) holds a catalog of the firm's own fields and lists. The catalog is where a firm names the details its practice collects, for example a list of children or a roster of fiduciaries, and a package decides which of them a given matter type asks for. A matter only ever shows the fields and lists its package calls for, which is why a prenuptial never sees an estate plan's questions.

Assembly: from intake to finished documents

Every matter has an Assembly tab that carries a single engagement from intake to finished documents. It walks three steps in order:

• Collect is where the client's answers and files come in: intake submissions and any documents the client uploads, behind one switcher. See Intake for how submissions are sent and reviewed.
• Resolve is the worklist of what still needs filling before documents can come together.
• Produce is where the matter's documents are generated and move out to the client.

You move between the steps freely; the stepper shows where you are without forcing the earlier ones to be "done" first.

Resolve: what's left before drafting

Resolve answers "what's left before I can draft?" in one place, without opening each template to find out. It groups the open items by who owns them:

• What needs the firm is editable right there, inline, and saves as you go.
• What needs the client points back to intake, where the client's answers come from.
• What's derived is filled by the platform from facts already on the record, so there's nothing to type.

When the matter's package calls for them, Resolve also captures the lists a plan turns on, like specific bequests or the people who serve as fiduciaries, right alongside the single fields. A matter whose package doesn't ask for those lists simply doesn't show them.

Produce: the matter's document set

Produce works from the canonical client record that intake review produced. The package already knows which documents this matter should generate, so a single action assembles the whole set rather than making staff create each document by hand. Where a plan can take one of several forms (a joint trust or two single trusts, one kind of deed or another), the platform picks the right one from the facts on the matter.

Change a detail in the record and regenerate, and every affected document picks it up. On a joint matter, generating a document lets staff choose whose copy it is (one spouse, the other, or both) and give the copy a label, so a couple's parallel documents stay distinct. Documents move through draft, ready, and shared with the client, with Word and PDF copies available to download at each step. That movement is what advances the matter through Drafting and Reviewing.

Seeing what fed each field

From Produce, opening a generated document shows a field view of what fed each part of it. A staffer can look at it three ways: the fields on their own, the fields beside the document, or the document in full. Fields are grouped by whether they still need attention, are ready, or were recorded but aren't used by the current template. Firm-owned values can be corrected inline from the same view. It's the mirror of Resolve: Resolve is where the firm puts details in, this is where the firm sees where each detail landed.

Revising a document in Word

Generated drafts rarely survive contact with an attorney unchanged, and the place to change them is Word, not a web editor. From a generated document, Revise in Word downloads the current copy with track changes already on, and notes on the matter who took it out and when (a note, not a lock). When the edit is done, Return revision brings the file back.

Before anything is accepted, the return is checked and summarized: how many insertions and deletions, whether the file is the one the platform handed out, whether it was based on an older copy than the current one, and whether any literal tags were left in the text. Most importantly, if the edit changed a value that came from the client record (a name, a date, an address), each such change must be resolved explicitly: update the record, so every document agrees, or keep it as an override in this document only. Accepting creates a new numbered revision and returns the document to draft; reviewing and re-sharing are deliberate steps, never side effects.

Every revision is kept. The document's history lists each one with who made it, when, and an optional note; any two revisions can be compared as an inline redline over the document; and any earlier state can be restored, which lands as a new revision rather than rewriting history. Regenerating a revised document starts a fresh copy from the record; manual edits from earlier revisions aren't carried into it, but they remain in the history for comparison.

Sharing pins what the client sees: a client always gets exactly the revision they were sent, even if the firm keeps revising afterward, until staff share again. One boundary to know: a revised engagement letter can't go out for e-signature; generate a fresh copy and send that instead.

The engagement letter

The engagement letter is the one document signed electronically. It generates from the firm's letter template, goes out for e-signature, and the executed PDF lands on the matter when the ceremony completes. The scope the client signed is anchored to the matter from that moment.

Estate planning documents themselves (wills, trusts, powers of attorney, healthcare directives) execute in person, the way the formalities require. The platform tracks the workflow around the ceremony (scheduling, confirmation, wrap-up) rather than substituting for it.

Documents, uploads, and the Drive mirror

A matter's files live in the Assembly tab: client uploads under Collect, generated drafts and executed PDFs under Produce. A firm that connects Google Drive in Settings → Integrations also gets a mirrored folder per matter, kept up to date automatically, so the same file set is wherever the firm already works. Mirroring stops when a matter is archived.