Multi-signer workflows

A contract can have more than one signer. Common patterns:

Two-party contract, one company-side signer (you) and one client-side signer. Pre-sign at compose handles your side automatically.
Co-signers, two people on the client side both have to sign (e.g., a married couple buying a service together).
Witness, a third party signs as a witness without being a contractual party.
Countersign step (legacy), client signs first, then you (or another admin) countersign as the company. With pre-sign at compose as the default since the Pre-sign rollout, the UI path always pre-signs and this state is essentially unreachable from the human composer. Where the countersign path still does fire: MCP / agent sends where the API-key minter has no saved signature on file, and pre-rollout contracts that are still sitting in awaiting_countersign.

Adding signers

In the contract composer, the Signers section lets you add as many rows as you need. Each signer needs:

Name — what gets printed under their signature on the PDF.
Email — where the signing-link email goes.
Role — client, company, or witness.

Order matters only for the legacy company-countersign pattern (see below). For everyone else, signing happens in parallel.

Parallel signing

By default, every signer gets their email and signing link at the same time. They can sign in any order. A signs Monday, B signs Tuesday, B signs at 9am, A signs at noon, doesn't matter.

The contract status moves through:

sent, emails are out, nobody's signed yet.
viewed, at least one signer opened their link.
signed, all client/witness signers have signed. If pre-sign at compose populated your side too, this is the final state.
awaiting_countersign, only reached when you explicitly skipped pre-sign at compose. All non-company signers are done; waiting on you (the company) to countersign.
signed (final), the company has countersigned.

If your contract has no company-role signer, you skip awaiting_countersign entirely and go straight to the final signed state.

The legacy company countersign step

The UI composer doesn't expose a way to skip pre-sign on purpose. The Send button is gated on a captured signature, and the default is to apply your saved signature automatically. So the countersign step is rare in practice.

The two paths that still land in awaiting_countersign:

MCP / agent sends without a saved signature. If the admin who minted the API key the agent is using hasn't saved a signature at Settings → Signatures, the agent's call to send_contract or send_quote ships the contract unsigned. The response includes a warning so the agent can flag it. Saving a signature once fixes every future send from that key. See MCP server for the agent-side details.
Pre-rollout contracts. Anything sent before the Pre-sign rollout that's still in awaiting_countersign keeps the old flow. The countersign UI on the contract detail page is unchanged for those.

When you would deliberately want this workflow:

A different person on your team (a partner, legal counsel, the principal) needs to review the executed copy before binding.
Your internal policy requires a human review of every client-signed contract before it goes live.
You want the option to back out after seeing what the client agreed to.

For the multi-admin case, the cleanest current workaround is to have the partner mint their own MCP key without saving a signature on their account; sends from that key will land in awaiting_countersign for the partner to manually countersign.

When you reach the countersign form (on the contract detail page at /admin/contracts/<id>), you sign the same way clients do — type, draw, or use a saved signature. After your signature, the contract is fully executed:

Both parties get a final signed PDF.
The PDF is saved to the client's Documents tab.
The audit PDF reflects every signer's IP, UA, and timestamp.

What the per-template `requiresCountersign` flag does

Templates have a requiresCountersign boolean (shown in MCP list_contract_templates as requires_countersign). With pre-sign at compose as the default, this flag is informational — it only fires when pre-sign was skipped (the two paths above). You can leave every template's flag at its default and behavior is identical to having it off.

Saved signatures

If you sign contracts often, save your signature once in Settings → Signatures. After that, every outgoing quote and agreement uses it automatically at compose time. Quote and agreement composers have a signature pad on the right side where you can pick a different signature mode (typed vs drawn) per send if you ever want to.

Clients can also save their signatures from their portal once they've signed at least one document. Saved signatures speed up the next signing flow.

Resume on abandon

If a signer opens the signing page but doesn't finish (closes the tab, gets interrupted), the partial state is saved. When they come back through the same signing link, they resume where they left off — typed text, drawn signature, opted-in fields are all preserved.

Duplicate-email guard

The composer prevents you from listing the same email twice as a signer on the same contract. If you need one person to sign in two roles (e.g., as the client AND a witness — unusual but possible), use slight email variations or address it offline.

Decline by a signer

Any signer can click Decline on the signing page instead of signing. When they do:

The contract status moves to declined.
You get a notification with their declined reason (if provided).
Every other signer's signing link is invalidated — nobody else can sign.

You'd typically void the contract at this point and follow up offline.

Signer-specific fields

If your contract template has merge fields ({{signer:name}}, {{signer:email}}, {{signer:title}}), each signer's fields get filled in their own copy of the rendered PDF. They see their own info pre-filled when they open the signing page.

Inviting a signer to the portal

When a client signs a contract, they're auto-provisioned a portal account if they don't have one. Co-signers and witnesses don't get auto-provisioned — they sign and leave. If a co-signer needs portal access later, add them as a CustomerMember from the client's workspace.

Reordering signers

The order in the composer is the order signers appear in the audit log + signed PDF. It doesn't affect when emails go out (parallel) or when signing happens.

Removing a signer

You can remove a signer from the composer before sending. After sending, removing requires voiding the contract and creating a new one with the corrected signer list.