Sending for signature
What this page is — building a signature request on a sealed document, following it to completion, and the rules that refuse, remind, reassign and void.
What it is for — so signatures are collected on the sealed copy, in the right order, from people authorised to sign, with the evidence attached.
The problem it solves — a signed PDF emailed back proves very little, and chasing signers in the wrong order wastes days.
Route: the Signatures panel on /org/papers/documents/<document> · Permissions:
Send signature requests/envelopes. to create and send; Void an in-flight signing ceremony. to void
1. What it is
A signature request groups one or more finalized documents, an ordered list of signers, a verification method and an expiry. It is sometimes called an envelope. Each signer gets a private link to the signing page.
| Signature request | Approval | Counterparty accept | |
|---|---|---|---|
| Who acts | Named signers, inside or outside the organisation | Internal approvers | The counterparty |
| Document state required | Finalized | Any approval state | Open to the counterparty |
| Produces | A signed PDF with a certificate and verification code | An audit entry | A state move |
| Legally | Execution | Internal consent | Agreement in principle |
2. Why you would use it
- The evidence travels with the document. The certificate page lists each signer, the time, the consent text and the hash chain. Anyone can check it on the verification page years later.
- Signers are invited in order. In sequential mode each signer is emailed only when the one before them has signed. Nobody chases the second signer to sign first.
- Only authorised people sign. The signatory matrix refuses a signer who may not sign this type or value before the request goes out, not after a contract signed by the wrong person.
- Mistakes are recoverable. Wrong email? Reassign. Terms changed? Void it and send a new request. Everything is recorded.
3. Step by step
- Finalize the document first.
- Open Signatures → Send for Signature.
- Fill in the drawer (§4). Add counterparties, customers or contacts from the search, or type a name and email.
- Send. With sequential order you see "Only the FIRST signer is emailed now — each next signer is invited automatically when the one before them signs." With parallel order: "All signers receive their invitation email immediately."
- Follow the request on the panel: status, mode, verification method and expiry. Each signer row can copy the signing link to share by another channel.
- Use Remind, Reassign or Void as needed (§5).
Where signatures land on the page
Placement comes from the signature anchors in the template. The drawer has no manual field placement. A template without anchors still collects valid signatures, recorded on the certificate page, but nothing marks the body of the document.
4. Field reference
| Field | Required | Options and defaults | Exact messages |
|---|---|---|---|
| Title | Yes | e.g. NDA signature — Acme Corp | "Title is required" |
| Add more documents | No | This document only — pick others to bundle. Every document must be finalized | document "…" must be finalized before requesting signatures |
| Signing order | Yes | Sequential — one signer at a time, in order (default); Parallel — everyone signs at once | — |
| Signer verification | Yes | Email OTP — 6-digit code before signing (default); Magic link only — no extra verification | SMS codes: "sms_otp is not supported by the native provider yet" |
| Signers (in order) | At least one | Name and email per row | "Every signer needs a name and an email" / "at least one signer is required" |
| Expiry | No | A date | "expires_at is in the past" |
The signatory matrix
If the organisation's signatory matrix does not authorise a signer for this document's type or value, the drawer shows The request was refused with the rule. Change the signer, or ask an administrator to add a matrix rule.
5. Following, correcting and stopping
| Action | Allowed when | Refusal |
|---|---|---|
| Remind | Signers are still pending | request in status "…" has no pending signers to remind |
| Reassign a signer | The request is open and that signer has not signed | "name and email are required"; request in status "…" cannot be reassigned; signer in status "…" cannot be reassigned |
| Void (Reason required) | The request has not ended | request in status "…" cannot be voided |
Reassigning replaces the old link. The previous person now sees link_superseded. Voiding cannot be
undone — create a new request.
Statuses
| Status | Meaning |
|---|---|
| draft | Created, not sent |
| sent | Invitations out, nobody signed yet |
| partially_signed | Some signers done |
| completed | Everyone signed — signed PDF built |
| declined | A signer declined, which closes it for all |
| voided | Stopped by the sender |
Voiding is normal: when terms change after sending, voiding and resending is the correct move.
6. Worked example
Supply Agreement SA-2026-008, finalized. Signers: Kestrel's director, then Acme's CFO.
- Title Supply Agreement — Kestrel / Acme, sequential, Email OTP, expiry 30 April.
- The matrix allows the director, who is not internal, but refuses a junior Acme manager who was typed first by mistake. The owner replaces him with the CFO, Rahul Menon.
- Sent. Only the director is emailed.
- After three days without a signature, the owner clicks Remind.
- The director's assistant replies that the director is travelling. The owner reassigns to the deputy director with a new email, and the old link stops working.
- The deputy signs, and Rahul is invited automatically and signs.
- The status becomes completed. The signed PDF with its certificate is attached, and the owner
receives the completion notice. The type has an
all_signedtransition, so the document moves to executed.
7. The admin contract
| What must be configured | Otherwise |
|---|---|
| Documents finalized before requesting | Requests are refused |
| Signature anchors in templates | Signatures appear only on the certificate page |
| A signatory matrix, if authority limits apply | Anyone can be named as a signer |
| Requires signature on types that must be signed | Documents can go into force unsigned |
An all_signed transition on those types | Completion leaves the document in its state until someone moves it |
| Voice attestation on the type, where wanted | No spoken attestation step |
| Outbound email | Copy signing links and share them yourself |
Only the native signing provider is available. Selecting another answers that it is not configured, and third-party verification needs a non-native provider.
8. Downstream
- Completion builds the signed PDF and certificate. It records a fully executed event, fires
paper.fully_executed, and notifies the sender. - Declines notify the sender with the reason.
- The signed PDF's code shows the signed flag on verification.
- Obligations are not created by signing. Extract them at closing.
9. Don't confuse this with…
| Submitting for approval | An internal decision, before sealing |
| The signing page | What the signer sees |
| Share links | Read-only delivery |
10. Troubleshooting
| Symptom | Cause |
|---|---|
| "…must be finalized before requesting signatures" | Finalize every bundled document first |
| The request was refused | The signatory matrix does not authorise that signer |
| The second signer received nothing | Sequential order — they are invited after the first signs |
| Completed, but the document did not move | No all_signed transition on the type |
| One decline ended the whole request | By design — send a new request once resolved |
| Signatures are not on the page body | The template has no signature anchors |
| Remind refused | Nobody is pending, or the request has ended |