Documents and templates
Your own Word templates, assembled from the client record.
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.
A firm that practices in more than one state keeps one library rather than one per state: a document that has to differ by jurisdiction holds a file for each, and the matter's governing state decides which one generates. See working in more than one state.
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.
A publish that turns out wrong is recoverable. Any earlier published version can be restored as a draft, bringing back its Word file and all of its mappings, which you then review and publish like any other draft. Walking a bad publish back doesn't mean re-uploading the old file and redoing the mapping by hand.
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, choosing from the facts a matter already holds:
- 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.
- Whether there's a spouse or partner. The clause that speaks to a spouse appears when the matter names one, and drops when it doesn't.
- A condition on one of the firm's lists. Whether the list has entries at all, how many, whether any or every entry matches a given choice, or whether any entry is under an age. This is how a will's guardianship clause appears for minor children and stays out for grown ones, without anyone answering a "do you have minor children" question the matter already knows the answer to.
- How many people hold a role on the matter. A clause can turn on the number of people serving in a given capacity, so a trust that names one successor trustee doesn't recite a cascade of blanks for the second and third, while a matter that names three gets the full sentence.
- Whether the matter has one client or two. The same template then serves an individual and a couple.
The through-line is that the author binds to a fact the matter already records, rather than adding a question to keep in sync with it.
…I direct that my just debts be paid from my estate.
If any child of mine is a minor at my death, I nominate Maren Whitcombe as guardian of the person and estate of each such child.
I give the residue of my estate to the Trustee of the Trust…
Park, Jiwoo & Hana · youngest child is 9 · clause included
…I direct that my just debts be paid from my estate.
Guardianship clause dropped
I give the residue of my estate to the Trustee of the Trust…
Whitcombe, Eleanor & Thomas · children 37 and 34 · clause dropped
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 draft says so on its own row, and the way to act on it is refreshing the document.
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.
A people list carries more than its questions: it can also say how it behaves when a client meets it, such as opening with the client's spouse already first in line for an office. See who serves, and in what order.
A field the practice has moved on from can be retired rather than archived. Retiring closes it to new use: a newly published form, package, or document template can't add it, and its row reads Retired in place of Unused. Everything already built on it carries on. A questionnaire sent while the field was live keeps asking and recording it, and every answer already given stays readable, which is why the confirmation names how many open asks and submitted answers still depend on it. Its label and client-facing guidance stay editable. Archiving is the harder stop, and the platform refuses it while any sent questionnaire still depends on the field, offering Retire instead.
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.
Within each group the open items come first, and the ones you've already handled fold away behind a Show N completed line. Nothing is taken out of reach, and a field you set stays where you can find it in one click, but a nearly finished matter reads as the short list of what's actually left rather than a wall of ticks with the gaps scattered through it. A field you fill this session holds its place until your next visit rather than jumping into the fold while you're still typing.
What needs the firm 2 open
edits save as you goWhat needs the client 1 open
from intakeWhat’s derived 0 open
filled from the recordWhen 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.
The people a matter names are grouped by the client who named them, then by position, so a joint matter's two chains of successors read as two chains rather than one interleaved list. Each client's own line says how deep their chain goes, whether there's a backup behind the office holder or nobody yet, and the section's roll-up reports the worst of them rather than the best. A required list nobody has filled in reads as one gap per client, each with its own place to add, so filling in one spouse's agents never makes it look as though both are done.
Choices that only a clause depends on get a row here too. If a document in the matter has a section that turns on a firm-defined choice, that choice is editable in Resolve and in Edit matter even when nothing else on the matter asks for it, so a document added by hand is never left with a branch nobody can set.
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.
The alternatives the matter didn't pick, and any document whose condition the matter doesn't meet, fold away at the bottom of their package behind Show N not in scope as long as nothing has been drafted for them, so the lane reads as the plan this matter is actually producing. They're chosen by the matter's facts rather than by hand, so what changes one is a change to those facts.
Joint revocable living trust
Pour-over will · Eleanor
Pour-over will · Thomas
Durable power of attorney · Eleanor
Certification of trust
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. Where the row already belongs to one of them, as each spouse's own will or healthcare power does, there is nothing to choose: the dialog states whose copy it is and generates that one, so a row can't be drafted from the other spouse's point of view and then filed under this one. The choice stays open on rows the couple shares. A package running for someone other than the client names its copies the same way, after the people it's planned for and in the order it lists them, so the row tells you whose document it is wherever it appears.
Documents move through draft, ready, shared with the client, and Done, with Word and PDF copies available to download at each step. The icon box at the start of each row tints as the document moves along, plain paper for a draft, then reviewed, shared, and done, so a glance down the lane says how far each one has got before you read a single pill; once a selection has started, that box is also where you tick the row. A copy saved from a matter's document row arrives named with the client's surname in front of the file's own name, so a morning's downloads from several matters don't land in one folder as a stack of identical file names. Where the document belongs to one spouse rather than the couple, that person's first name is added to the end, so a joint matter's two healthcare powers don't save over each other either. That movement is what advances the matter through Drafting and Reviewing.
A matter can also carry a document the firm has no template for, added a la carte from the scope or the Billing tab. It appears here as a document row marked Awaiting document and takes no part in generation, because there's nothing to merge; it finishes when someone links the finished file or marks it done. See documents the firm has no template for.
A document fulfilled by a file the firm uploaded, whether or not a template exists for it, reads Fulfilled and shows the file on the row under Fulfilled by, with the same door out to the client a generated document has. Share on that row (Add share once someone holds it) sends every fulfilling file to the people you pick in one step, with the same email notification, the same bounced-address flag, and the same roll-up as a document share, and the row then lists who holds the files as chips you can revoke from. Someone holding only part of the set, because a file was added after the share, is marked as such, and Add share again covers the rest. Unlink on a file takes it out of the slot without deleting it or withdrawing anything already shared: the file stays with the matter's uploads as a supporting file, and if it was the last one the row goes back to awaiting its document. Renaming or deleting the file itself still lives on the Uploads tab. What the client sees is one list: a shared upload appears under Documents in their portal alongside the documents the firm generated.
Nobody has to tell the platform the drafting is finished. Once every document the matter's answers call for has a draft, the matter counts itself as drafted and the next action becomes sharing. A matter still waiting on an answer that decides whether a document belongs in the set isn't finished drafting, so it holds; narrowing the plan so that question no longer applies finishes it just as generating the last document would.
Finishing a document
Done is what a document is when the firm is finished with it. Usually it gets there by being shared: the client has it, and marking it done closes that loop. But plenty of documents never need the portal at all, like an instrument wet-signed in the office or a deed handed over in person, so Mark done is also offered directly on a reviewed document. It sits in that row's overflow menu rather than inline, because sharing is still the ordinary path and this is the deliberate exception. Marking a document done without ever sharing it is recorded as exactly that.
The same selection that shares a set also moves one. Select a package's worth of documents and Mark reviewed or Mark done applies to all of them at once, which is the honest shape of the work: a staffer reads through a plan and signs off on the plan, not on fourteen separate rows. Anything in the selection that the action doesn't apply to is skipped and counted in the summary rather than raised as an error, so a selection that swept up one extra row never turns into a failure you have to unpick.
Marking a document reviewed can be taken back. Mark as draft, in a reviewed row's menu, returns it to draft without touching its contents, for the ordinary case of someone signing off a beat too early. A document the client is already holding isn't reviewable back this way: a shared document is a statement the firm made, and it walks back through unsharing or a revision instead.
A Done document is meant to be safe to rest on, so its menu narrows to match. Everything that only reads stays: inspect the fields, download the Word or PDF copy, look at the history, and share it with the client, which is bookkeeping on a finished artifact rather than a step backwards. Everything that would change the document underneath you is gone, and getting it back is one named action, Reopen, which asks before it acts. Reopening puts the document back where it was, either shared or ready depending on whether a client is holding it, and the full menu returns with it. What Reopen doesn't undo is a signature: where a signed engagement letter fixed the matter's scope and price, those stay matter facts.
The point of the narrowing is that the old menu had a trap in it. Refreshing a Done document quietly returned it to draft and pulled it out of the client's portal, which is a reasonable thing to want and an unreasonable thing to discover by accident.
When a detail changes on the record after a document was drafted, the document's row says Data changed since this draft, and the step's summary counts how many documents are in that state. Clicking through opens the refresh review, described in refreshing a document.
Sharing a document with the client
An estate plan is a portfolio, not a document, so sharing is built around the set rather than around one file. Ticking the checkbox in any group heading turns checkboxes on across the whole list and selects that group, so a selection can span packages freely, and each heading then reads how many of its documents are picked. Choose what you're sending and share the batch in one dialog, or take the Share with client action from the matter and start with everything shareable already picked. Clear, on the selection bar, empties the selection and puts the list back the way it was. Sharing is where a document leaves the firm, so it says what it's about to do before it does it. Where a selection holds nothing that can be shared, the bar's Share button says so rather than opening a dialog with nothing in it.
You pick who gets it from the people on the matter, with the firm's own clients selected to begin with (both spouses on a joint engagement, including on each other's per-person copies) and everyone else listed unselected. Each recipient is emailed one message listing everything newly shared with them, rather than one email per document; a couple receiving a fourteen-document plan gets two emails, not twenty-eight. Someone with no email address on file still gets access in the portal; the dialog says so rather than implying they were notified. An address the firm's mail has bounced off before is flagged here as it is everywhere else. Anyone who was already holding every document in the batch is not written to at all, because nothing about their portal changed.
The email is a checkbox, not a given. Send email notification is on by default, so the ordinary share is unchanged, and turning it off shares the documents into the portal with nobody told they're there. That's the one to reach for when the client is sitting in front of you, or when the message that should carry the news is one you're writing yourself.
A document still in draft can't be shared, and shows in the dialog as needing review first. Documents already marked Done appear too, unselected and set apart, since the reason to reach for a finished one is adding a recipient who missed it. If a single document won't convert for sending, it's named in the summary and skipped; the rest still go, because one awkward file shouldn't cost the client the other thirteen.
You also choose the format, and it's a real choice rather than a default nobody sees. PDF is the default and is what the client should normally get. Sharing the editable Word file instead is offered plainly and warned plainly: the client can change it, and the PDF is the reviewed record. Either way the client gets a clean copy: the firm's tracked changes and margin notes never travel with it.
Updating a document that's already out with a client is handled the same honest way. A client can't be left holding a live link to a copy the firm has replaced, so a document that changes after it was shared returns to draft and leaves the client's portal until someone reviews it and shares it again. Both the refresh review and the return-a-revision flow say that before you commit.
The updated copy is never shared automatically, because the point of reviewing before sharing is that someone reviews it. Sharing again is a deliberate second step, and the row points you at it. Each recipient keeps whatever copy they were last sent, so re-sharing is what moves a client forward, and a document whose recipients are holding an older copy is flagged Revised since shared.
Sharing the last of a matter's documents moves the matter on, and it does so whichever way you shared them: the bulk dialog, a single row, the action on the matter. Sharing some of them doesn't, because the work isn't finished. This is the lifecycle reading what actually happened rather than which button did it.
Sometimes the rest genuinely aren't coming: a document is being handled off the books, or was drafted and dropped. Once at least one document is out with the client, Move to reviewing appears on the matter's own menu and records that the matter is with the client, without emailing anyone anything. It opens a confirmation rather than firing on the click, and it isn't offered at all before something has actually been shared, so it stays a repair rather than a shortcut.
The execution set
Day of signing wants one file, not twenty. Once every document in the matter's scope has been generated and marked reviewed, and none of them is waiting on a refresh, the Document set strip above the Produce lane offers Build execution set. Until then the strip says what has to happen first, how many still need reviewing or refreshing, and the button isn't there at all. Its presence is the gate: the set is the thing that gets executed, and an unreviewed instrument mustn't be able to enter it.
Building produces one merged PDF of the whole set: the instruments themselves in order, each at its current revision, with any document fulfilled by an uploaded file in its slot. Nothing is added in front of them, so if the firm wants a cover page it places its own cover template first, like any other document. The engagement letter stays out, and so do signed copies: the set is the stack that goes to the signing table, not what comes back from it. A matter with more than one package can build the set for one package at a time.
The order is the matter's order. It starts as the package's own sequence, and staff can change it by dragging rows on the package's card on the matter's Overview; the Produce lane and the set read the same order. Rows that fold away as not in scope hold no place in it.
Once built, the set sits on the strip with its date, its document and page counts, and three doors: the PDF, Word, one Word file holding every generated document in the set for staff and never shared (a document fulfilled by an uploaded PDF has no Word copy, so it isn't in it), and Share. If a document changes afterwards, or documents enter or leave the set's scope, the strip reads Documents changed since this set. If only the sequence changes, it reads Order changed since this set. Choose Rebuild once the documents are ready again. Nothing rebuilds on its own, because what was printed for a ceremony should stay what was printed, and earlier builds stay listed behind a disclosure. A stale set can't be shared until it's rebuilt.
Share opens a recipient dialog; once someone holds this build, the button reads Add share and offers the remaining people. Select who should receive the plan and whether to Send email notification, which starts on. Each document in the set is shared with the people you pick, and the matter moves on to Reviewing the same way as a bulk document share. With notifications on, each recipient with an email address gets one message naming the plan and listing its documents. Turning notifications off still gives portal access; a recipient without an email address can also receive access without an email.
In the portal the client sees one entry, their complete estate plan, with the individual documents beneath it; the phrase execution set is the firm's, and the client never sees it. See the client portal. Revoking the set share takes back the merged plan only. The documents beneath keep their own shares and are withdrawn one by one, as they were given.
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.
The inspector also carries the document's available actions, so you can download, revise in Word, refresh, mark reviewed, or share without returning to the Produce list. The choices follow the selected document's current state, just as they do on its row.
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.
Each time you take a copy out, it comes out clean: earlier rounds are already part of the text, and the marks you see are the ones you're about to make. The same is true of anything the client sees, so neither a PDF nor a shared Word file carries the revision history or the margin notes the firm was keeping for itself. Download Word, in the row's menu, hands you the same clean copy with tracking off, for reading or printing rather than editing; the firm's own margin notes come along, since those are for staff.
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 is put to you as a comparison rather than a quoted string: the field by name, what's on file for it, what the draft printed, and what's in this document now. You choose one of two consequences, neither preselected. Update the matter record to match this document names the other live documents that print the same detail and warns they'll read as changed until they're refreshed; keep this wording in this document only leaves the record as it is. Choosing the first records the decision with the revision rather than editing the record for you; the dialog points you to the matter's details, Edit matter or the person's record, to make the change itself where you can see what you're changing. Accepting adds the edited copy to the document's history and returns the document to draft; reviewing and re-sharing are deliberate steps, never side effects.
A Word file that came back outside that flow can still be brought in: from
the matter's files, promoting an uploaded .docx makes it the document's
current copy. If the document has moved on since that file was taken out,
promoting it says so and asks you to confirm before the upload takes over,
rather than letting the older file win quietly.
Refreshing a document from the record
A document is generated once, then evolves. When the record has moved on, Refresh re-merges the document from the matter's current data and the current template version, and the result becomes the newest entry in that same document's history. There is no second copy to keep track of and no separate pile of earlier drafts; the document a client asked about last month is the document in front of you, with everything that happened to it underneath.
Refresh opens a review before it does anything, in the same shape as intake review: each field that resolves differently now is listed with the value in the draft beside the value on the record, so you can see what a refresh would actually change. If the document was edited by hand since it was last generated, that work is listed too, under Not carried forward, naming each edit, who made it and when. A refresh over hand-edited work only proceeds once you acknowledge that list. The machine never quietly overwrites a person's work.
If the document is currently visible to the client, the review says so, and refreshing returns it to draft and takes it out of the portal until you mark it reviewed and share it again.
The review is a decision, not a commitment. If what it shows is that the record is wrong rather than the draft, close it, correct the detail in Resolve or in the document's field view, and refresh once the record says what it should.
The document's history
Every state a document has been in is kept. History is a plain timeline, newest first, of what happened and who did it, interleaved with what each client was given and when:
- Edited in Word by a named staff member, with the note they left and how much changed
- Refreshed from matter data
- Restored earlier content
- Shared with a named person, or a share withdrawn
Its two jobs are orientation and restore. Any earlier state can be restored, which moves the timeline forward rather than rewriting it: nothing is ever deleted. Any two states can be compared as an inline redline over the document, which is the same rendering the return-a-revision review uses.
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 and the price the client signed are anchored to the matter from that moment.
One boundary to know: a letter that has been edited by hand can't go out for e-signature, because what goes out has to be what the platform produced. The row says so, and names the way forward: refresh the letter from the template, mark it reviewed, then send it. The hand edits stay in the document's history; the fresh merge doesn't carry them forward.
A signing request is addressed to the email it went out to, and that address is fixed for the life of the request. If a signer's email has since been corrected on their record, resending refuses rather than sending a second invitation to the old address and hoping. It offers the honest fix instead: Revoke & re-issue, which cancels the outstanding request and sends a fresh one to the address the firm now has.
While a letter is out for signature, its row says where it stands in plain words: 0 of 2 signed, 1 of 2 signed, then Waiting on attorney once every client has signed, since the attorney signs last and the request isn't complete until they do, Finalizing signing once the last signature is in and the signing service is closing out the request, and Signed once the executed copy has landed on the matter. Beside it sit the date the request went out and the most recent reminder the signing service confirms it sent. Signing details opens the rest: each signer with their role and the address the request went to, whether they've opened the document and when, when they signed, and every reminder that has gone, each with its time and recipient. Nothing here is inferred from an email being opened; a reminder is listed only when the signing service confirms it.
The row also carries a follow-up date. Clients due and a date show while client signatures are outstanding, and once the date has passed the row reads Client signatures overdue. The date is the firm's own target, set in client communications: it cancels nothing and doesn't stop a late signature, it says when to start asking. The funnel board carries the same one-line reading on each matter at Convert, with a link into the row.
If the request stops at the other end, expired, declined, or revoked, the row reads Signing stopped with the reason beneath it, the matter holds at Convert with the way forward on the row, and the firm's bell says the signing needs attention. The bell also rings once when the whole request completes, attorney included, and never for an individual signature, a reminder, or a document being viewed. Both are on by default and can be turned off in client communications. If a cancellation you asked for couldn't be confirmed at the other end, the row says the old link may still work and asks you to check there before assuming it's dead.
Resend invite asks before it acts, because it emails every signer still waiting straight away. The document and the links already in their inbox are untouched, and the matter's waiting-on-signature clock restarts from the nudge, so the board reflects the fresh ask rather than the original one.
A firm working in more than one state keeps a letter for each. Because a letter goes out for signature, a state with no letter of its own holds the send and says so, rather than sending another state's terms and hoping the review catches it. See working in more than one state.
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.