From Draft to Active Contract: What the Signature Actually Starts in the CRM
Most small firms do not lose contracts. They lose the moment a contract was signed. The PDF is somewhere, the client is happy, and yet nobody can say on Thursday whether the work may start, who was supposed to order the materials, or when delivery was promised. The paper exists; the state of the deal does not.
Firmspace CRM treats a contract as a live record in the finance section rather than an attachment in a folder. The record moves through a definite set of states, and every move leaves a trace. The contracts list lives at /crm/finance?tab=contracts, next to quotes, orders and invoices.
The assistant can create the contract itself. Its create_contract tool takes a customer name, an optional contact, a total value, a currency, and optional start and end dates, and it links a matching contact or creates one — there is no need to search the CRM first. The tool creates a draft. It does not create an active contract, because nobody has signed anything yet.
Changing that state is a separate tool, contract_action, with exactly three values: sign, complete, and cancel. Sign moves a draft to active, complete closes an active contract, and cancel stops a draft or an active one. The tool description carries the condition that matters: it needs user confirmation unless auto mode is on. There is no fourth value and no way to skip a state.
Behind the assistant there is an ordinary route for the same step, and it is stricter than the button might suggest. The signature endpoint works on draft contracts only: if the contract is already active, the request is refused with a plain sentence rather than quietly accepted a second time. Two signatures on one contract is exactly the kind of duplication a CRM should prevent.
A successful signature writes three things that answer three different questions. The first is the state itself: the contract becomes active and the signing date is stored, so the question “may the work start?” has one answer instead of five opinions.
The second is the automation signal. The signature sends an event of type contract_signed carrying the contract number, the customer name, the deal it belongs to, the value and the currency. On its own that event does nothing at all; it is a statement of fact that other machinery is allowed to react to.
The third is the paper trail. An audit entry records the action, the contract, the number, who signed it and the amount, so the change is attributable months later. Alongside it, the document chain writes an event to the feed of the deal, the contact and the company the contract is linked to. One act, and the whole chain of relationships knows about it.
What makes the signature genuinely useful is what happens next, and crucially, that nothing happens by default. There is no hidden workflow that orders materials the moment a client signs. There is a list of events the CRM can raise and a list of actions a rule can take: notify someone, create a task, add a note, move a deal to another stage, send an email, call a webhook, or run an AI step. A contract signature hard-wires none of them.
So the question to ask is not what the CRM does after a signature, but what your firm wants to happen. If signing should put “order the materials” in front of a person, that is a rule somebody had to write. If the deal should stop sitting in the wrong stage, that is a rule too. The event is complete and dependable; the intent behind it has to come from a human.
There is a second, quieter path into the same record, and it is worth separating from the first. When the assistant reads an uploaded PDF of a contract, its read_document tool returns the text, and the save_employee_contract tool proposes writing extracted fields to an employee profile: the contract type, the start date and a short note. That is the employee card, not the contract record in the finance section. The two are neighbours, not the same thing.
Both paths meet at the same guard rail. Nothing the assistant proposes about a contract happens on its own: it presents the action, and a person confirms it. Even with auto mode switched on, the rule that governs the assistant is that reading text from outside — a document, a mailbox, a card, a web page — removes its right to change records without asking. Text inside a contract is data, never an instruction.
That is a deliberate design decision, and it is the right one for a document with money attached. A contract sits exactly at the boundary where a wrong click is expensive and a prompt-injected PDF is plausible. The assistant may read it, summarise it, draft a new one and offer to sign it; the consent to sign stays with the person, and the audit entry names that person afterwards.
The practical consequence is that the signature is not a formality at the end of a process, it is the hinge of it. Before the signature the contract is a draft, editable and harmless. After it the state is fixed, the evidence is written, and the rest of the firm's work can safely depend on it. The system is built so that this hinge is visible, and so that whoever turns it is known.