Matters and people
The single thread of an engagement, and the humans on it.
The matter
A matter is the engagement itself, one thread from first inquiry to closing. It carries the stage, the people involved, the intake record, documents, appointments, invoices, files, and the full activity history. There is no separate "lead" object that later becomes a "client" file; the matter that entered at Contact is the same matter that closes.
When a client already has a matter
A client who calls about something new often already has a matter open, and the right home for what they're asking about is sometimes that matter rather than a fresh one. So New matter stops before it creates, whenever a party you're attaching is already the client on an active matter at the firm. It lists those matters, each with its type, which side it's on, what stage it's reached, when it opened, and who else is on it. Each row opens the matter.
Opening one of the listed matters is usually the answer when the new work is really the same engagement growing: widening the matter type, adding a second client and attaching another package are all things you do on the matter itself. Create a new matter anyway does exactly what you asked, and is the right call for a repeat engagement or a genuinely separate one; the fact that you saw the others and went ahead is kept on the new matter's record. Change the parties takes you back to the form.
It never blocks. A second matter is often correct, and the platform's job here is to make sure nobody creates one without knowing the first exists. Closed and archived matters never trigger it, so a returning client with a finished plan walks straight through, and being a contact on someone else's matter doesn't count either.
People
A person is anyone the firm deals with: a prospective client, a current client, a spouse. People exist independently of matters and can appear on more than one. When a new inquiry arrives, the platform matches it against the people it already knows instead of minting duplicates, and flags ambiguous matches for review.
From a person's record, staff can preview as client: open the client portal exactly as that person sees it. The preview is read-only and clearly marked as such, so a staffer can check what a client is looking at, before they've ever signed in, without standing in for them or changing anything.
A person's record also lists the matters they touch and how. Being a client of one is the common answer; being a named contact is another; and where a matter is planning for someone else, that person's record says so and names the package. It's how the firm answers "why is this person in our records" for someone who never signed anything.
The people a matter names
Beyond the client or clients, an estate plan names others: trustees and successor trustees, guardians, beneficiaries. Staff add these while assembling the matter, in the Resolve step, when the engagement's package calls for that roster, and capture only what the documents need (a share, whether a gift passes per stirpes). An email address is required for the client, who signs and uses the portal, but optional for the others, who may only ever appear inside a document. Each person is recorded once on the matter and reused wherever the documents refer to them.
Who serves, and in what order
An office and its successors are one list, not two questions. Whoever is first on a healthcare agent list holds the office, and the people below are the successors in the order they appear, which is the order the document recites. Lists that work this way label their rows 1st, 2nd, 3rd rather than counting them off, because on these the order is the answer. Changing who acts first means moving a row, not editing a field, and in Resolve each row of a chain carries move up and move down, so re-ordering a chain is two clicks rather than removing someone and adding them back.
Where the office isn't a choice at all, the question isn't asked. Some instruments name their own first office holder in the text, and there the matter is asked only for the successors, with the list labelled that way so nobody reads position 1 as the office itself.
A firm can have one of these lists open with the client's spouse already at position 1, which saves re-typing the answer a good many couples were going to give. It's set per role in the firm's catalog, it only fills in where the record actually says who the spouse is, and it's a suggestion rather than a fixture: the client can remove it or move it, and their own choices land at 2 and 3 as the successors. Staff can still change the order afterwards on the matter.
Joint engagements
Couples are first-class. A joint matter carries both spouses: both named on the matter, one shared intake that both can work in, and per-person answers where the law cares about the difference (each spouse's own healthcare agent, for example). You never manage a couple as two disconnected files.
Who the firm represents is always a decision a person makes, never one a form makes. An inquiry that arrives on its own opens a matter with the person who sent it as the client; if they mention a spouse, that spouse arrives as a proposal for staff to judge in the review queue, where promoting them straight to second client is one of the choices. Either way an attorney or admin has to say so.
An engagement that starts solo doesn't have to stay that way. When the planning conversation pulls a spouse in, Add client, in the Parties section of Edit matter, adds them to the live matter, matched against the people the firm already knows. Nothing is abandoned or re-created: the history, the signals, the submissions and the signed scope all stay put. Because work already set up for one client doesn't split by itself, the platform then shows you exactly what the second client implies, the documents and forms that exist per person and would now need a counterpart, and you choose what to add. An email address is optional for a second client, as it is for anyone else on the matter who isn't the one signing.
Price follows the same "shown, never silent" rule. Where the matter's package charges a couple differently, and the matter is still sitting at the price it got as a solo engagement, adding the second client offers to move it to the joint price, with the number in front of you. Accepting it is a click and declining it is a click; nothing reprices itself. A matter whose engagement letter is already signed is left alone, because the signed letter is the deal.
Either client's name or email finds the matter in search, so a joint matter turns up when you look for the spouse who wasn't first on it.
Correcting who the client is
Sometimes the wrong person is on the file. The child calls, the child is recorded as the client, and the plan is really for the parent. Each client in the Parties section of Edit matter carries three fixes for that, available to attorneys and admins:
- Make primary moves the "first client" designation to another client on the matter. The primary is who signs first, who portal and booking email goes to, and who new invoices default to, so the client you promote needs an email address on file.
- Replace person… swaps one client for another in a single step. The replacement takes the same place, primary or not. Anything the original client already submitted stays exactly where it is, as their answers; the items they had not started yet move across, and anything already drafted or answered for them is retired and re-created for the replacement, with the list shown to you before you confirm.
- Remove takes a client off the matter. It is never available on the last client on a matter, where Replace is the fix instead. The person stays in your directory with their whole history, and if they were the primary, the longest-standing remaining client takes over.
Each one asks you to confirm, and the confirmation spells out both what changes and what does not. Nothing regenerates on its own: drafts already produced keep the identity they were produced with and show the "Data changed since this draft" note until you refresh them.
These fixes close once you have told the client who they are. As soon as a document, an uploaded file or a complete estate plan is shared with a client, or the engagement letter has gone out and signing has begun, the three actions disappear and the card says which of those happened. A shared document is a statement to your client about who your client is, and quietly rewriting it afterwards would not be a correction. From that point the repair is a new matter. Closed and archived matters are read-only in the usual way.
Roster entries such as trustees and agents are never deleted by any of this. An entry belonging to someone who is no longer on the matter is flagged "no longer a client on this matter" on the Prepare lane, so you can resolve it where it lives.
Facts the documents draw on
Some details a plan turns on are more than a single value. Staff can record specific bequests (an item and who receives it) and disinheritances (a person, and how they're related) while assembling the matter, when its package asks for them, and they flow into the documents that reference them. Staff can also record a person's gender, so generated documents read with the right pronouns rather than awkward placeholders.
Status, stage, and billing are separate axes
A matter's status (active or closed), its lifecycle stage, and its billing state move independently. Payment doesn't gate drafting; closing doesn't erase an unpaid invoice; an archived matter keeps its stage for when it's reopened.
Editing matter details
Staff edit a matter's descriptive fields (scope, custom fields, the matter-type tag) from the matter header. A firm that works in more than one state also sets the matter's governing state here, the fact that decides which version of each document the matter generates; see working in more than one state. The agreed price sits here too, as currency fields rather than free text: what the engagement costs, any upfront payment, and an hourly rate where one applies. See billing for what that price then drives.
Once an engagement letter has been signed, what the client signed is anchored: edits that would drift from the signed scope or the signed price are surfaced rather than silently absorbed, and changing them after the fact takes a deliberate unlock.