Per StirpesDocs
For firm staff

Documents and templates

The firm's own templates, written in the browser or in Word, assembled from the client record.

Templates are the firm's own

A template is written one of two ways. A browser template is written, edited, compared and published right in the platform, with the page showing as it will print. A Word template is the firm's existing .docx, uploaded as-is and mapped once so it can generate from the client record ever after. Both kinds sit in one library, grouped into categories the firm controls, and a Word template can be moved into the browser when the firm is ready, keeping its Word file alongside.

Where your firm drafts in the browser, a matter document made from a browser template opens in the document workspace rather than being downloaded to Word. Word templates and the documents drafted from them keep working exactly as below, so a matter can hold both.

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 an edition for each, and the matter's governing state decides which one is used. See working in more than one state.

Writing a template in the browser

The library is organized by instrument (the document as the firm thinks of it, a last will say) and its editions (the text for a state, and for one client or a couple). New template starts with the instrument: name it, choose its category, and Create instrument. Then give the first edition its document name, state and planning structure; Create and edit opens its first draft in the editor, and Skip for now leaves the instrument in the library reading No editions yet, with Add edition for later. The same page offers Upload a Word document and, with Publish, Fork a platform default.

Letter templates are set up from their slot in Engagement settings. Set up letter template asks How to start: Create new opens an empty letter in the firm's letterhead, and Import from Word builds it from the letter's published Word editions, one letter template whose state wording follows the matter's state. After that the slot reads Open letter template, with a line saying whether new letters use it yet.

Viewing and editing

Opening an edition shows it read-only first, the published version if there is one, and looking never starts a draft. Edit starts a draft from the publication; when a draft is already saved, the page says so and the button reads Resume editing. The draft is marked Draft until it's published. Exit editor saves and returns to the view, keeping the draft for later. Discard draft throws the draft away and returns to the published version; an edition that was never published leaves the library, and its instrument stays.

The editor works like a word processor on the document's own pages. Its Insert menu adds what makes the document a template:

  • Field: a value from the matter, such as a client's name or a matter field. On a letter it also holds the fee terms and each signer's signature and date (Client 1 signature and date, Attorney signature and date, and Client 2 signature and date, which goes inside the passage for both clients). These land as boxes over the letter's own signature lines, so the template keeps its layout and needs no underscores. A letter template doesn't publish until every signer has one signature box and one date box, with Client 2's inside that passage.
  • Office: the office's name, address and other details.
  • Fact: a new matter field the template needs, defined as you insert it.
  • Passage: a conditional passage around the selected paragraphs, table row or words. You choose the condition that decides it and how it relates to the passages around it: on its own, inside another, or alternative wording for one.

The Template details panel beside the page lists every field and passage, where each one is used and what it's bound to, and Highlights marks them on the page. Sample data, at the foot of the editor, shows the saved template filled in for a matter you pick, read-only, so you see what a real matter would print before any matter depends on it. Changes lists what the draft changes against the last published version; an edition started blank has nothing to compare until its first publication.

Publishing

Publish makes the draft the new published version. Every published version is kept, and History compares any two of them. Publishing reaches matters with care. A browser draft nobody has reviewed yet picks up the new version on its own, keeping the attorney's edits and asking about any passage where an edit and the template change collide; see when the template changes for reviewed and shared documents. After a publish the header reports how many drafts were updated, how many are still pending, and how many need review.

Moving a Word template into the browser

On an instrument whose editions are Word files, Edit on a published edition brings it into the browser the first time, turning its tags and sections into fields and passages and reporting what it changed. The Word file stays as the edition's source. The browser copy has to say what the Word file said, so the draft is compared with its Word starting point, for each state it covers and for one client and for a couple, under Differences. Compare current draft checks again after you edit. Where a difference is intended, Accept differences records who accepted it and when; once the draft changes again, it asks to be compared and accepted again before publishing.

Using a template for new documents

Publishing doesn't by itself change how matters draft. Use for new documents, in the published view's menu, turns the edition on: from then on, a matter that needs it drafts it in the browser instead of merging the Word file. Disable for new use turns it back off. A document already drafted stays the kind it was drafted as. Letter templates have the same switch, Use for new letters.

Offices in a template

The firm's offices are kept in Settings, on the Firm tab, and Manage offices in Engagement settings goes straight there. A browser template prints an office's details through office fields. An edition picks its office under Office for this edition, and an edition that prints office details needs one before it can be published. A letter template's office is set with the letter, in Engagement settings, under Office settings: one office every letter uses, with exceptions by state. Saving it applies to letters not yet sent. A reviewed letter it affects goes back to draft for review, and a letter already sent stays as it went.

Tags: mapping a template

A Word 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 Word document stays pinned to the version it was merged against, so revising a Word 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. A browser template does the same with a conditional passage, inserted from Insert and bound to the same kinds of fact.

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 (available with Packages and Catalog → View) 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.

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.

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 produce, so nobody has to create each document by hand. A document whose edition is used in the browser shows Open: it starts its draft on first open, even while some answers are still missing, and opens the same draft every time after. The Word documents in the set are generated together with Generate ready Word, which drafts every Word document whose required details are in and leaves anything already generated alone; Generate Word picks one Word template by hand. Open plan opens the whole set in the document workspace. 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.

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. A label you give becomes the document's title wherever it's shown, rather than being added after the template's name. 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. A document added on its own for someone else, a deed for a client's parent say, is fixed the same way: the dialog names who it's for and offers no choice.

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.

Beside the date, each row says how its current copy got there. A browser draft reads Editing now and who has it open, or Saved with when it was last saved. A Word document reads Generated for a first draft, Refreshed after a refresh from the record, Edited after a Word revision came back, Replaced when an uploaded file took over, Reverted when an earlier copy was restored from history, and Uploaded on a row fulfilled by a file. Anything other than a plain first draft reads a shade darker, so a row someone has worked on stands out from one that's only been generated.

Two status words belong to browser documents. Needs review is a draft that was reviewed and then taken back into editing, so the earlier review no longer stands. Shared · edited, needs review is a shared document that's been edited since (see after review), and Pull from portal, in the row's menu, takes a shared copy back out of the portal. A row whose text is another state's edition carries a chip naming that state, and an action such as Switch to the Oregon edition moves it to the edition for the matter's state. Switch all, beside the generate actions, does the same for every document on the matter that can switch. See working in more than one state.

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 done applies to all of them at once, and so does Mark reviewed for the Word documents among them (a browser document is reviewed in the document workspace, and a browser letter takes no selection at all). That 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. For a Word document, 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 browser document goes back into editing from the workspace, and reads Needs review until it's reviewed again.

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.

When a detail changes on the record after a Word 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. A browser draft needs no refresh: wording nobody has touched follows the record on its own, and the workspace asks only where a change meets an edit.

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. A browser document offers the same choice: its PDF of record, or a clean Word copy of the reviewed version. A signed browser engagement letter is the exception, shared only as its signed PDF.

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 Word document that changes after it was shared leaves the client's portal until someone shares it again. A browser document works the other way round: the client keeps the copy they were given while the firm edits, the row reads Shared · edited, needs review, and the new copy reaches them only when it's reviewed and shared again. A refresh returns it to draft, so it needs reviewing first; a returned Word revision comes back already reviewed, ready to share.

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. Move to reviewing, on the matter's own menu, records that the matter is with the client, without emailing anyone anything. It opens a confirmation rather than firing on the click. It's held back while the matter's drafts are generated and none has been shared yet, so it stays a repair rather than a shortcut; the lifecycle sets out when it's offered, including for a matter the firm isn't drafting.

The execution set

Day of signing wants one file, not twenty. The Document set strip above the Produce lane reads where the matter stands: Ready for execution, or how many of its documents are ready and how many need attention, with Document details for the drafting counts behind it. Once every document going into the execution has been reviewed, and none is waiting on a refresh, the strip offers Build execution set. Until then it says what has to happen first, 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.

A document that isn't being signed this time can be left out of the execution from the document workspace. The strip then reads N left out, which opens the list, and the set is built from the rest.

Building produces one merged PDF of the 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 of the documents 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 what's left out changes, it reads Selection changed since this set; if only the sequence changes, 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 set 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, unless a document left out of the execution is still outstanding, in which case no share moves the matter on. With notifications on, each recipient with an email address gets one message about the set and its documents. Turning notifications off still gives portal access; a recipient without an email address can also receive access without an email.

Building is never a recipient act. A rebuild takes nobody's copy away: each person keeps the build they were given until you share a newer one with them. The set's row lists who holds which build, with Share latest to bring one person up to date, which replaces their earlier build, and Withdraw this shared set to take one person's set away. Withdrawing asks first, sends nothing, and leaves the documents that person holds on their own shares.

In the portal the client sees one entry with the individual documents beneath it. It reads Complete estate plan only when the set is the whole matter's plan with nothing left out; a set built for one package, or one with documents left out, reads Estate plan documents instead, so the client is never told a partial set is the whole plan. The phrase execution set is the firm's, and the client never sees it. See the client portal.

Choosing the property a deed describes

A matter can hold more than one piece of real estate, so a deed never guesses which one it conveys. The matter keeps a Properties list (address, parcel number, legal description and county), and each deed the firm prepares in the platform names one property from that list. Its address, parcel number and legal description all come from that one record, so they always describe the same parcel.

The choice is always yours, even when the matter has a single property. On the deed's work item in preparation, before the deed is drafted, the Property for this document control offers three ways in:

  • Choose a property picks one already on the matter, then Use this property saves the choice.
  • Add a property records a new one and selects it in the same step. An address is enough to save it; the deed itself says which details it still needs before it can be marked reviewed.
  • Start from earlier values appears on a matter that already holds property details in Edit matter, from before the Properties list existed. It proposes those details as a new property for you to check or edit, then creates and selects it. Nothing is matched or moved behind your back: the matter's existing fields stay as they are, and so does every document already drafted from them. Once a property on the matter holds those details, the action no longer appears.

Once the deed is drafted, its fields fill from the chosen property. Editing that property later updates every deed that chose it and no other, and reordering the list changes nothing. Inside the document, Change property switches a deed to a different property in one step: fields you haven't touched follow the new property, wording you changed by hand stays and is flagged for you to decide, and the copy from before the switch stays in the document's history.

If a property is removed from the matter, a deed that chose it keeps its wording and reads Property unavailable until you select another or clear the choice. A deed whose required details come from a property can't be marked reviewed while no property is chosen, or while the chosen one is missing a detail the deed requires.

A deed drafted from a Word template reads the property details in Edit matter, while a deed that chooses a property reads that property. When a matter has both, the deed's property control says so, and so does Resolve, so a change you make in one place isn't mistaken for a change in both.

A deed also says who is on each side of it. Its Grantors and, where it names receiving people, its Grantees are chosen for that deed: the people it starts with come from the template, and you can change either side for one deed without changing who the matter is planned for or anyone's place on the matter. The template sets those starting points under Deed assignments, with a Default for new deeds for each side and how many people it supports; each deed keeps its own choice once it's made. Untouched names, addresses and pronouns in the deed follow a change of people; wording you edited by hand is flagged for you to decide. A Word deed's assignments sit in its field view, and changing them refreshes that document, with the earlier wording kept in its history.

The Properties list lives in the firm's catalog like any other list. Renaming one of its details, for example "APN" to "Parcel number", never disturbs the documents or values that use it. Removing a detail, changing its type, or archiving the list is refused while anything still depends on it; retiring it is not.

Seeing what fed each field

From Produce, opening a generated Word 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. A browser document shows its fields beside the page in the workspace instead; see fields and the matter record.

Revising a document in Word

Generated drafts rarely survive contact with an attorney unchanged. A browser document is changed where it already is, in the document workspace; a Word document is changed in Word. From a generated Word document, Revise in Word downloads the current copy with track changes already on, and the row reads Revising with the date while the copy is out; hovering over it shows who has it. That's a note, not a lock. When the edit is done, Return revision brings the file back. If the copy isn't coming back, Cancel revision in the row's menu clears the note without touching the document.

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 marks the document reviewed, because whoever returns a revision has just read it in Word. If that shouldn't stand as the review, Mark as draft on the row takes it back. Sharing is still a deliberate step, never a side effect: a document the client was holding leaves their portal until you share the new copy.

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. A promoted file lands as a draft, since nobody has reviewed it yet. 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

This section is about Word documents; a browser draft follows the record on its own (see fields and the matter record). A Word 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. For a Word document, History, in the row's menu, 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. A browser document keeps its own history in the workspace; see history and kept copies.

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.

Where the firm's engagement template is used in the browser, the Draft engagement letter dialog opens the new letter on its own page. You edit and review it there and send it from the same page with Send for signing: the reviewed PDF goes to the signers in signing order, each signing where the letter's signature boxes sit (see letters), and while it's out for signature the letter doesn't change. On the Produce row, Open returns to the letter and View signing status shows where the request stands. To send different terms, Revoke and reissue withdraws the request and opens a fresh draft from the same template, with the current matter values, that everyone signs again; the old letter stays as history, reads Revoked, and offers Open replacement. A browser letter prints the firm's logo at the top of its letterhead, beside the office address, from Logo in letters on the Brand tab.

A signed paper copy uploaded to the matter is filed with the letter, but linking it doesn't record the engagement on its own. On a browser letter that's reviewed but not yet sent for signing, Mark signed (paper) or Mark done records completion; once a request is live, Mark signed (paper) is the one that remains, as below. Either way the scope and price are taken from the reviewed letter, never read from the uploaded file.

The rest of this section reads the same for both kinds of letter, except where it says Word. One boundary to know: a Word 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. On a Word letter, 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. On a browser letter, Revoke and reissue is the way to reach a corrected address.

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 signing on each matter at Convert too: how many signatures the matter is still waiting on, with a short Overdue beside it once the date has passed, and 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.

Two more actions sit beside it while a request is live, for when the signing happens some other way or shouldn't happen at all. Each asks before it acts.

  • Mark signed (paper) is for a letter the clients signed on paper, at a meeting say. It asks for a reason, which is kept with the record, then records the letter as signed and closes the request, and the matter moves on exactly as it would after an electronic signature. The row then reads Marked signed. The signing service isn't contacted, so invitations already sent stay live until they expire on their own.
  • Cancel signing, on a Word letter, withdraws the request: the signers' invitations stop working, and the letter stays on the matter. It can't be undone, but it isn't the end of the letter. The row reads Signing stopped, and Reissue signing request sends a fresh request to the current signers, who all sign again. The same button is the way forward when a request stops at the other end. While a browser letter's request is live, Revoke and reissue takes the place of both.

While a request is live the letter offers no Share, so it can't be sent to the portal in the middle of its own signing.

The disengagement letter, which closes a matter, is previewed before it goes. A Word disengagement letter is saved only when it's sent: closing the dialog before Send leaves nothing behind, so Produce lists only Word letters that actually went out. Where the firm's disengagement template is used in the browser, Send disengagement opens the letter on its own page, which saves as you work, to edit and review, and it's sent from there with the matter's closing choice.

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.

Viewing firm templates

What View, Edit and Publish allow on Document templates and Engagement letters is set out in working without a permission. Working on matter documents, including choosing a template to generate from, is separate from these setup permissions.

Website inquiries

How the Settings → Capture tab brings inquiries from the firm's own website into a matter, and invites the person to continue on the firm's contact form.

The document workspace

Drafting, editing, reviewing and preparing a matter's documents in the browser.

On this page

Templates are the firm's ownWriting a template in the browserViewing and editingPublishingMoving a Word template into the browserUsing a template for new documentsOffices in a templateTags: mapping a templateSections that turn on and offPackages and the catalogAssembly: from intake to finished documentsResolve: what's left before draftingProduce: the matter's document setFinishing a documentSharing a document with the clientThe execution setChoosing the property a deed describesSeeing what fed each fieldRevising a document in WordRefreshing a document from the recordThe document's historyThe engagement letterDocuments, uploads, and the Drive mirrorViewing firm templates