E-signatures

Ask someone to sign — a countersignature on an approval, an agreement, a waiver — from a workflow. Each signer gets their own link, the platform records who signed what and when, and the signed PDF carries a certificate page stating exactly that.

Requesting a signature

A signature is asked for by a workflow action: Request a signature, on entering a state — Awaiting signature, typically. You choose the notification template that carries the link, who signs (the assignee, the owner, the creator, or any email field on the form — a customer's own address, usually; a list field of addresses asks each email-shaped entry, up to twenty), and optionally which document template they sign. Name no document and the signer is shown a generated summary of the record instead. Each recipient becomes their own request, with their own link and their own evidence trail; re-entering the state never mails a second, competing link to someone whose request is still open.

The email's template carries {{signing_link}} the way a payment request carries its checkout link, and can merge {{form_name}}, {{signer_email}} and the submission's own field values — so the mail can say who is asking and for what, which matters for deliverability: a bare link with no context is the shape spam filters distrust most. The notification editor's Start from panel offers a ready-made Signature request template with exactly that structure. You can also set the consent wording the signer agrees to (there is a sensible default) and how long the link lives — 30 days unless you say otherwise, up to a year.

What the signer signs is frozen

At the moment the request is sent, the document is rendered once, stored, and fingerprinted — its SHA-256 digest is recorded on the request, and shown on the signing page. The signer reviews and signs those exact bytes: later edits to the record or the template change nothing about what their link shows, because a signature over a moving target would attest nothing. Before the signed copy is assembled, the platform re-reads the stored bytes and re-checks the digest; if they no longer match, it refuses to produce a certificate rather than certify something the signer never saw.

The signing page

The link opens an ordinary page — no account, no sign-in; the unguessable link is the whole of the signer's authority, the public-form discipline. It shows who the request was sent to, the document to review, its digest, and the consent wording. The signer types their name, draws their signature (or types it — the typed name is rendered as a signature, for anyone who cannot draw with a pointer), ticks the consent box and signs. They can equally decline, with a reason, and the requester sees both the refusal and the reason. A link that was cancelled, expired or never existed reads identically: not available. A link already signed keeps working — revisiting it shows when they signed and, once it is ready, offers their signed copy.

The evidence, and the certificate

Signing records the signer's stated name, the drawn signature, the consent wording as it was shown, and the when-and-from-where: timestamps for sent, first viewed, consented and signed, plus the signer's IP address and browser. The signed copy is then assembled — the frozen document, untouched, followed by a signature page and a certificate of completion stating the document's digest, the signer's identity claim, the timeline and the consent text. It lands on the record's Documents tab like any generated PDF, and the signer can download their own copy from their link. Every step is written to the audit log, with the signer — signer:their@address — as the actor.

This is a standard electronic signature with a recorded evidence trail — the kind most business paperwork runs on. It is not a certificate-based digital signature (eIDAS “qualified” signing), and Faldaro does not verify the signer's identity beyond their control of the mailbox the request was sent to.

Gating work on the outcome

The outcome is recorded on the submission as signature_status — requested, signed or declined — written by the server and only the server: a submitter sending the key themselves is ignored, exactly as with payment status. A transition can therefore require `signature_status` = "signed" before it can be taken. With several signers, signed means everyone asked has signed; one refusal reads declined; cancelled and expired requests drop out of the reckoning, so a mis-addressed request never holds the gate hostage — cancel it and ask again.

Managing requests

The record's Signatures tab lists every request with where it stands — queued, awaiting signature (and whether it has been viewed), signed, declined, cancelled, expired. From there you can copy the link, re-send the email (the same link, so nothing the signer already has goes stale) or cancel, which stops the link resolving at once. Requests never disappear: they are evidence, and cancellation is a status, not a deletion.

The signature field is a different thing

A Signature field on a form — the draw-here box a submitter fills in as part of submitting — is available on every plan and involves no request, no link and no certificate: it stores the drawn image with the submission. Signature requests — the links, the evidence trail, the certificate — are included in the Team plan and above. The plan gates publishing a form that asks for signatures; requests already sent keep working whatever happens to the subscription, and the signing page never behaves differently because of it.