Flowgrammer

E-Signature Automation

Design send, remind, void, decline, complete, and download with a named SignatureEvidence log and verified callbacks.

— Craig Major

You can run send, remind, void, decline, complete, and download as a named signing-control path. A SignatureEvidence log, the event log in this guide, stores each verified callback against a bound document so a retry cannot rewrite yesterday’s file. The Signing Workflow Requirements Workbook gives you the field list, that log, twelve worked cases, and a factual vendor matrix.

Start from Document Processing Automation if you still need to pick a first workflow. If the missing job is a named approve, reject, or request-changes decision, use the published Document Approval Workflow. A completed signature is not that decision.

Who this is for

Use this when documents already go out for signature and the missing piece is a control plane: who may send, how callbacks are verified, when a PDF is actually ready, and which writes stay forbidden.

The download includes:

  • Statuses and signing verbs that stay separate from approve, reject, and request-changes
  • SignatureEvidence fields for request id, event id, template version, verification, and artifact_ready
  • A callback checklist for HMAC, event hash, client-id echo, and Event-Id dedupe
  • A forbidden-downstream sheet for payment, bank-detail change, final accounting, auto-renew, and auto-terminate
  • Twelve Cedar & Quay cases, including a verified complete, a duplicate event, a failed verification, decline, void, a stale template, a completed-before-downloadable wait, an unauthorized sender, blocked auto-pay, blocked auto-renew, approval required before send, and sequential versus parallel routing
  • An unranked vendor matrix for DocuSign, Dropbox Sign (including the HelloSign name), Adobe Acrobat Sign, PandaDoc, SignNow, SignWell, Zoho Sign, and Jotform Sign

You still need one document family for the first build, a named sender, named signer roles, and a place to keep the event log. Confirm whether your plan includes Connect, callbacks, delayed routing, or webhooks before you promise those surfaces to a team.

Keep neighboring jobs on their own pages. If the file still needs an org decision, use the published Document Approval Workflow and the Document Approval Status and Role Matrix. If the file lives in Dropbox, Drive, Box, or Notion and the job is internal approval, use the published Dropbox, Google Drive, Box, or Notion approval guides. If the pain is unread PDFs, use intelligent document processing. If the job is a money register, use invoice processing automation or the Google Sheets invoice tracker. If the job is a renewal register, use the contract tracker.

Approval versus signature

Internal approval is a named person saying the organization accepts a version. E-signature is a named person applying a vendor-hosted signature to a bound document. Those jobs can sit next to each other. They do not share a log.

PandaDoc’s current Help, accessed 9 September 2026, places a Submit for approval step on a template before Send document. That is a pre-send gate inside the signing product. It is not Flowgrammer Document Approval DecisionEvidence. DocuSign routingOrder sequences recipients. That is signing order. It is not an approval workflow.

A completed signature does not renew a contract, terminate a contract, authorize payment, change bank details, or write a final accounting row. Those stay on the contract and invoice pages.

What the signing-control model owns

Closed statuses stay small: draft, ready_to_send, sent, in_signing, then completed, declined, voided, or expired. Side states record the messy middle: partially_signed, viewed, waiting_for_downloadable, callback_failed, duplicate_event, unauthorized_sender, stale_template_version. An optional overlay, internal_approve_before_send to approved_to_send or send_blocked, records a vendor pre-send gate. Do not rename that overlay approve.

Signing verbs stay closed too:

  • send_for_signature
  • remind
  • void or cancel
  • decline, from the signer
  • complete_signature, observed through a verified vendor event
  • download_completed_artifacts

Remind notifies. It does not complete. Timeout can expire the request or escalate a note. It does not auto-complete, auto-renew, or pay.

SignatureEvidence field list

The SignatureEvidence log is the durable record. After this section, this page calls it the event log.

Every material callback writes a row, or is refused. The reader columns are:

Field Job
signature_request_id Vendor envelope, agreement, or signature-request id
event_id Vendor delivery id used as the idempotency key
template_id and template_version Bound template. A later version is stale
document_hash_or_vendor_doc_id Bound document
sender Named sender. A shared inbox is not enough
signer_roles Role matrix, ordered or parallel
routing_policy sequential, parallel, or mixed
auth_method_declared Only a vendor-documented option
event_type Exact vendor event name
event_received_at Listener timestamp in UTC
verification_result HMAC, event_hash, client-id, or Event-Id check
artifact_ready Downloadable or certificate ready
downstream_action Agreed handoff after complete
downstream_ref Idempotent write receipt
human_authority_gate Named person for any post-sign file or notify

Keep duplicate_key as lower(signature_request_id)|lower(event_id) and downstream_write_count as 0 or 1. The same event_id is ignored.

Callbacks, verification, and idempotency

Vendors push events. Your listener verifies, stores, and acknowledges. It does not trust a body because the URL looks familiar.

Official surfaces, all accessed 9 September 2026:

  • DocuSign Connect documents HMAC headers named X-Docusign-Signature-N. The HMAC Help and Validation pages on developers.docusign.com rendered as JavaScript shells in this draft fetch, so treat Connect enablement and key UI as tenant-confirmed. Do not assume every account has Connect on.
  • Dropbox Sign sends multipart/form-data with a json field. HTTPS is required. The listener must return HTTP 200 with the exact body Hello API Event Received. event_hash is HMAC-SHA256 over event_time plus event_type using the API key. Account callbacks and app callbacks are different scopes. Official retries run up to six times, then email; ten consecutive failures clear the URL. Requests time out after about 30 seconds.
  • Adobe Acrobat Sign sends an HTTPS GET with X-ADOBESIGN-CLIENTID when you register a webhook. You must echo that client id in the header or JSON body. The same header rides on later notifications. Official docs give the app 5 seconds to respond and recommend a queue. Failed deliveries retry for about 72 hours, then the webhook can disable. Resource-level webhooks are the documented best practice for a single agreement.
  • PandaDoc requires HTTPS, may deliver an array of events, and asks the listener to finish within 20 seconds. Official docs cap subscriptions at 300 per workspace and retry failed deliveries three times. X-PandaDoc-Webhook-Event-Id stays stable across automatic and manual retries.
  • SignNow event subscriptions need an API free trial, an active API subscription, or a Site License. Official docs say an API subscription is separate from a business plan. HMAC uses a secret_key you set. The hash arrives in X-SignNow-Signature.
  • SignWell posts JSON events. Official developer docs list document_completed, document_signed, document_declined, and document_canceled. Official guidance hashes event.type + @ + event.time with the webhook id as the HMAC-SHA256 key and compares event.hash.
  • Zoho Sign’s feature page, accessed 9 September 2026, says webhooks are currently supported on the enterprise plan. Confirm that gate in your tenant before you promise a listener.
  • Jotform Sign’s Help, last updated 27 May 2026 and accessed 9 September 2026, places webhooks under Sign Builder Integrations and notes a 30-second request timeout.

Failed verification writes nothing to the event log. A replay of the same event_id writes nothing a second time. downstream_ref stays the first receipt.

Routing and timing honesty

Signing order is recipient sequence. Shared order values can run in parallel. A template mismatch can drop expected fields or open free-form signing on some products. Confirm the official routing setting in the tenant you actually use. Do not call that sequence an approval workflow.

Timing is a second honesty problem. Dropbox Sign’s walkthrough, accessed 9 September 2026, says signature_request_all_signed means required signers finished and signature_request_downloadable means final files are ready. File the PDF on the downloadable event. PandaDoc publishes document_completed_pdf_ready as a distinct event from a generic state change. SignWell’s developer article notes the completed file can take a few seconds to appear after document_completed. Adobe’s webhook guide tells you to fetch signed documents through the API rather than assume the notification carries the full audit PDF.

If the vendor says wait, the status is waiting_for_downloadable. Do not file a final PDF early.

Forbidden downstream

These writes stay blocked even after a verified complete:

  • payment
  • supplier bank-detail change
  • final accounting post
  • auto-renew
  • auto-terminate
  • legal interpretation as an automation outcome
  • claiming jurisdiction-wide legal validity

Allowed after verified complete plus artifact_ready plus a named human gate: notify, and file the completed artifacts once.

Vendor matrix

This table is factual and unranked. It is not a buyer scorecard. Brand search volume is navigational and does not prove automation demand. App-neutral phrases such as e-signature workflow automation sit outside the Planner export used for this cluster, so volume is not supplied. Confirm plan and admin screens in your tenant. Later vendor-implementation pages are unfinished and are not linked here.

Vendor Official callback surface Verification to confirm Timing honesty Plan-gate honesty
DocuSign Connect listener X-Docusign-Signature-N HMAC; confirm Connect is enabled Prefer Connect over polling; retrieve audit events from documented APIs Scheduled sending and delayed routing are plan-category features. No seat prices here
Dropbox Sign Account or app callback URL event_hash; exact ack string Hello API Event Received Wait for downloadable after all signed HTTPS required. HelloSign is the legacy name for the same product lineage
Adobe Acrobat Sign POST /webhooks plus UI scopes Echo X-ADOBESIGN-CLIENTID on verify and notify Fetch signed document and audit through the API after complete Resource-level webhooks are documented as the better ISV pattern. 5-second ACK
PandaDoc Webhook subscriptions X-PandaDoc-Webhook-Event-Id dedupe; confirm authenticity guide in tenant Wait for document_completed_pdf_ready Array payloads. 300 subscriptions per workspace. Approve-before-send is not Document Approval
SignNow Event subscriptions secret_key HMAC in X-SignNow-Signature File after the documented complete event, not after an invite send API subscription can sit apart from a business plan
SignWell HTTPS callback plus event catalog HMAC-SHA256 of type@time with webhook id Completed can precede a ready PDF by a short generation delay Confirm current API and plan screens. No ranking
Zoho Sign API plus webhooks feature page Confirm current official verification in tenant Confirm download timing in tenant Feature page currently names the enterprise plan for webhooks
Jotform Sign Sign Builder Integrations webhook Confirm current official verification in tenant 30-second request timeout Help documents endpoint and size limits. No full API-parity claim

Worked example

Fictional Cedar & Quay Fabrication Ltd sends supplier agreement DOC-CQ-SIGN-014 version 1.0. Jordan Hale is the named sender. Morgan Reid signs as Supplier_Signer. Avery Chen holds the human gate for any post-sign notify or file action.

Jordan captures signature_request_id env:FICTION-CQ-SIGN-014, template tmpl:cq-sign-014 version v1.0, and a document hash before send. The routing policy is sequential. The listener stores UTC receive time.

A verified completion event evt:cq-sign-1401 writes one event-log row. artifact_ready is yes. downstream_action is notify. downstream_write_count is 1. Nothing pays a supplier and nothing renews the agreement.

The paired workbook walks twelve cases against that document. Samples stay fictional. There is no live vendor tenant in the pack.

The e-signature workflow

  1. Name the document family, sender, signer roles, and routing policy.
  2. If an org decision is required before send, open the Document Approval Workflow. Do not treat vendor approve-before-send as that record.
  3. Capture template id, template version, and document bind. Refuse send on a stale version.
  4. Send. Record signature_request_id.
  5. Remind only as a notification. Void only as a named cancel. Record a signer decline as declined.
  6. Verify every callback before the event log accepts a row.
  7. Ignore a replayed event_id.
  8. Wait for the vendor’s downloadable or pdf-ready event before filing the final PDF.
  9. After verified complete plus artifact_ready, a named person may notify or file once.
  10. Measure exceptions. Do not invent a benchmark.

What can run automatically, and what cannot

Event Automatic Review Human only
Store a verified callback Yes, after HMAC, hash, or client-id check Failed verification Turning a failed check into a complete
Ignore a duplicate event_id Yes First-write dispute Second downstream write
Remind Notify only Copy and timing Completing or voiding from a reminder
Decline or void Status update Whether artifacts must be withheld Filing those artifacts as signed
Completed before downloadable Move to waiting_for_downloadable Vendor event names Filing the final PDF early
Post-sign notify or file After verified complete plus artifact_ready plus named gate Destination path Payment, bank change, accounting, renew, terminate
Org approval before send Open or link the approval path Vendor pre-send gate Treating that gate as DecisionEvidence

Human decisions

A named sender confirms the bound document and template version before send. A named person confirms Connect, callback, delayed-routing, or webhook settings in the live tenant before those surfaces are promised. A named person reviews failed verification, unauthorized sender, stale template, decline, void, expiry, and a missing downloadable file. A named person decides any post-sign notify or file. Automation may notify and file only after those gates. It may not invent legal validity or org approval.

Failure paths

  • Missing signature_request_id or event_id. Stay in draft or sent. Write count 0.
  • Failed HMAC, event_hash, or client-id check. callback_failed. Alert. Write count 0.
  • Duplicate event_id. duplicate_event. Keep the first downstream_ref.
  • Decline stored as a signed PDF. Status declined. No completed artifacts.
  • Void after a partial sign treated as complete. Status voided.
  • Event cites template v0.9 after send on v1.0. stale_template_version.
  • Completed or all_signed before downloadable. waiting_for_downloadable.
  • Sender not in the named matrix, or wrong workspace. unauthorized_sender.
  • Listener tries to pay or change bank details. Policy block.
  • Listener tries to auto-renew or auto-terminate. Policy block. Use the contract tracker.
  • Vendor approve-before-send treated as Document Approval. Open the approval parent instead.
  • Extraction or OCR treated as a signature. Use intelligent document processing.

Test cases

The workbook uses fictional Cedar & Quay request ids. Expected control outcomes:

Case Input Wrong outcome Expected control
SX01 verified complete evt:cq-sign-1401, verification pass, artifact ready Payment or renew write One event-log row; notify; write count 1
SX02 duplicate event Same event_id replayed Second file write Ignore; downstream_ref unchanged
SX03 failed verification Bad HMAC or hash Event log write Alert; write count 0
SX04 decline Signer declines Signed PDF filed Status declined
SX05 void after partial Sender voids Silent complete Status voided
SX06 stale template Version v0.9 after v1.0 bind Send proceeds Exception or send blocked
SX07 completed before downloadable Complete event, artifact_ready no Final PDF filed Wait
SX08 unauthorized sender Riley sends Event log write Exception
SX09 auto-pay Complete tries to pay Payment write Blocked
SX10 auto-renew Complete tries to renew Contract update Blocked
SX11 approval before send Org decision still open Vendor pre-send treated as SoR Link Document Approval; send_blocked
SX12 routing mismatch Policy sequential, observed parallel Surprise free-form Exception

The paired workbook walks each case on its own sheet and in csv/case-recalc.csv.

What to measure

Record requests sent, share of callbacks verified before write, duplicate events suppressed, declines and voids that did not file a signed PDF, waits for downloadable artifacts, unauthorized senders blocked, auto-pay and auto-renew attempts blocked, and completes that have a notify or file ref. Keep those as definitions. Do not invent a benchmark, accuracy rate, or ROI figure.

There is no live production e-sign metric here, and no Flowgrammer customer signing case.

How to use the workbook

Download the Signing Workflow Requirements Workbook. It is an editable workbook and CSV pack, not a vendor Marketplace listing and not a live envelope store.

  1. Read README.md, then markdown/setup.md.
  2. Walk SignatureEvidence, CallbackVerification, and ForbiddenDownstream. Confirm Connect, callback, and webhook settings in your tenant before production.
  3. Import csv/signature-evidence-import.csv. Keep the internal names.
  4. Leave Config as_of at 9 September 2026 while you walk SX01 through SX12.
  5. Confirm SX01 writes once, SX02 does not write a second time, SX03 writes nothing, SX07 waits, and SX09 plus SX10 stay blocked.
  6. Answer the approval-versus-signature and legal-boundary questions. A vendor audit PDF is not a Flowgrammer certification.

The useful rules also sit on this page so the download is not the only answer. Packaged formulas use the Config as_of date and do not call TODAY().

Realistic limitations

  • This page designs signing control. It does not certify legal validity in any jurisdiction.
  • Connect, callbacks, delayed routing, and webhooks can be plan-gated. Confirm the current official tables in your tenant.
  • DocuSign HMAC pages returned a JavaScript shell during this draft fetch. Recheck those screens at publish time.
  • Vendor event names and retry tables change. Recheck official wording before you promise a listener.
  • Tenant screens differ. Confirm the screens you actually see.
  • This system does not approve a document for the organization, extract fields, pay anyone, or change supplier bank details.
  • This guide does not rank vendors and is not a pricing page.
  • The published DocuSign E-Signature Automation, Dropbox Sign E-Signature Automation, Adobe Acrobat Sign Automation, and PandaDoc E-Signature Automation implementation pages are live.

The published DocuSign E-Signature Automation guide is the first vendor adapter. The published Dropbox Sign E-Signature Automation, Adobe Acrobat Sign Automation, and PandaDoc E-Signature Automation adapters are live.

The published Dropbox Sign E-Signature Automation guide is the second vendor adapter. The published Adobe Acrobat Sign Automation and PandaDoc E-Signature Automation adapters are live.

The published Adobe Acrobat Sign Automation guide is the third vendor adapter.

The published PandaDoc E-Signature Automation guide is the fourth vendor adapter.

The published DocuSign vs Adobe Sign guide is the first vendor-to-vendor decision page.

  • This page is operational guidance, not legal advice and not a compliance certification.

Next step

Download the Signing Workflow Requirements Workbook for the event log, callback checklist, and twelve worked cases.

Keep the published Document Approval Workflow nearby when an org decision is required before send or after sign.

If senders, signer roles, or the event log are still unclear, start with an AI Success Audit. If those pieces are already named, book a fit call to scope an AI Automation Systems build.

Sources

Frequently asked questions

What is e-signature automation?

It is a named send, remind, void, decline, complete, and download path bound to a document and a verified event log. Signing order, vendor buttons, and a completed certificate are not Document Approval DecisionEvidence.

Is e-signature the same as document approval?

No. Signing executes a document. Approval is an org decision with a decision log. Use the published [Document Approval Workflow](/insights/document-approval-workflow) when that job is the one you need.

Does signature completion renew or terminate a contract?

No. That is a human decision on the [contract tracker](/insights/contract-tracker).

Does signature completion authorize payment?

No. Payment, bank-detail change, and final accounting stay on the invoice path. Never auto-write those from a signature event.

What is signing order versus an approval workflow?

Routing order sequences recipients. It is not Flowgrammer Document Approval. PandaDoc’s approve-before-send step is a vendor pre-send gate, not that parent record.

Why wait after “all signed” or “completed”?

Some vendors emit a later downloadable or pdf-ready event. File the final PDF when that documented event says the artifact is ready.

How do we verify webhooks?

Use the vendor’s documented check: DocuSign Connect HMAC, Dropbox Sign `event_hash` plus the exact ack string, Adobe `X-ADOBESIGN-CLIENTID` echo, PandaDoc Event-Id dedupe, SignNow `X-SignNow-Signature`, or SignWell `event.hash`. Confirm Zoho Sign and Jotform Sign verification in the current official docs for your tenant.

Is HelloSign different from Dropbox Sign?

HelloSign is the legacy name. Official Dropbox Sign developer docs still live on developers.hellosign.com. This hub does not create a separate HelloSign page.

Do brand search volumes prove automation demand?

No. Brand volumes are navigational. App-neutral phrases in this cluster were not in the Planner export, so volume is not supplied.

Can Flowgrammer certify legal validity everywhere?

No. Vendor docs plus counsel cover validity. This page automates process controls only.