Signature Workflow

How to use this docs page

This page is meant to answer one operational stage of the DullyPDF workflow well enough that you can run a controlled test without guessing. Read the sections below, validate the behavior against one representative document, and only then move to the next linked page.

That order matters because most setup failures come from mixing detection, mapping, fill validation, and sharing into one unstructured pass. A narrower review loop keeps troubleshooting faster and makes the template easier to trust once you save it for reuse.

Two entry paths, one signing engine

• Send PDF for Signature by email starts from the current PDF and freezes that exact record before send.
• Require signature after submit starts from a template Fill By Web Form Link, stores the respondent answers, materializes the filled PDF, then hands the signer into the same ceremony.
• Both paths converge on the same immutable PDF boundary before the signer sees the document, and both now begin with email verification on the public signing page.
• The owner workflow remains one request per signer, even when the UI saves recipient batches from pasted or uploaded TXT/CSV data.
• The owner signing popup ignores outside clicks; use the red X or Escape when you intentionally want to leave the draft flow.

Public signer ceremony

1. The signer opens the public /sign/:token route.
2. Email verification unlocks the immutable PDF for every emailed signing request.
3. Business requests then go through review -> adopt signature -> explicit finish-sign.
4. Consumer requests add a separate electronic-record consent step before review can continue.
5. Manual fallback can pause the electronic ceremony and switch the request into owner follow-up instead of forcing e-signing.

Artifacts and owner visibility

• Completed requests store the immutable source PDF, final signed PDF, audit-manifest envelope, and human-readable audit receipt.
• The detailed owner audit manifest records the request id, document category, immutable source hash/version, sender and signer identity fields, invite delivery metadata, OTP/verification state, ceremony timestamps, signature-adoption details, digital-signature metadata, and retained artifact hashes/paths.
• For consumer requests, that audit evidence also stores the disclosure payload and hash, the first-presented timestamp, the consent scope, and the access-demonstration evidence used before the signer can continue.
• The owner `Responses` tab in the signing dialog surfaces waiting vs signed requests plus signed-form and audit-receipt downloads.
• The owner `Responses` tab also offers a full dispute-package ZIP with the source PDF, signed PDF, audit receipt, owner audit manifest, validation snapshot, and delivery metadata.
• Template Fill By Web Form Link responses also surface linked signing status so the owner can download the finished signed copy or the same full package from the response row later.
• Signed PDFs are flattened before delivery so normal PDF viewers do not keep the underlying form widgets editable.
• Per-document signer-request caps are enforced server-side across both email and Fill By Web Form signing entry paths.

Audit log and E-SIGN alignment

DullyPDF is designed to support the core evidentiary mechanics behind the U.S. E-SIGN Act for ordinary business records and the product's consumer-mode ceremony. It does not rely on a single audit timestamp. Instead, it preserves the exact record, the signer actions taken against that record, and the retained evidence needed to reconstruct the ceremony later.

• Intent to sign: the signer must open the signing session, review the exact frozen PDF, adopt a signature mark, and explicitly finish the ceremony. E-SIGN defines an electronic signature as an electronic sound, symbol, or process executed or adopted with intent to sign.
• Logical association with the exact record: the ceremony is tied to the immutable source PDF hash and version, and the retained signed PDF plus validation record point back to that same source.
• Consumer disclosures and consent: consumer mode captures paper-copy, fee, withdrawal, contact-update, and scope disclosures, then requires affirmative consent plus the PDF access-check step before completion. That is the part intended to line up with E-SIGN's consumer-disclosure and reasonable-demonstration concepts.
• Retention for later reference: the source PDF, signed PDF, audit receipt, owner audit manifest, and public /verify-signing/:token page are retained so the record can be reproduced and checked later.
• Delivery and attribution evidence: the audit log also keeps invite provider/message metadata, verification state, session and network evidence, and completion timestamps so the owner can build a dispute packet without depending on the signer to preserve every email.

Official references: 15 U.S.C. § 7001 covers validity, consumer consent, and retention; 15 U.S.C. § 7003 lists excluded categories; the FTC/Commerce report on the consumer consent provision explains why the "reasonable demonstration" step matters for discouraging fraud and preserving access to written information in consumer workflows.

This is product documentation, not legal advice. DullyPDF is engineered to align with those core E-SIGN requirements, but document-type-specific laws, excluded categories, sector rules, and jurisdictional overlays still need policy or legal review before a team should claim support for a specific workflow.

PDF trust versus audit evidence

When no production PKCS#12 or Cloud KMS signing identity is configured, DullyPDF can still finish the workflow by self-signing the finalized PDF with its own certificate. In that configuration, PDF viewers such as Edge or Acrobat may label the embedded certificate as untrusted because the certificate chain does not anchor to a public trust store.

That viewer warning does not automatically mean the document was modified or that the workflow failed. The self-signed PDF seal still provides cryptographic tamper evidence, while DullyPDF's retained audit artifacts provide the higher-level workflow proof: immutable source PDF, signed PDF, audit-manifest envelope, audit receipt, and the public /verify-signing/:token validation page.

In practice, this means self-signed PDFs can still be sufficient for many internal, pilot, or ordinary-business workflows when the recipient is expected to rely on the audit log and retained validation record rather than a browser or PDF-reader trust badge. It should not be marketed as the same thing as a publicly trusted CA-backed signing certificate.

U.S. e-sign scope and guardrails

DullyPDF targets ordinary U.S. business e-sign workflows and is designed around core E-SIGN and UETA principles: explicit signer action, logical association with the exact record, retention-ready final artifacts, and paper/manual fallback when needed.

Excluded or higher-assurance categories still need separate legal review. The product should not be marketed as a notary, qualified-signature, or regulated-signature system unless that scope is added deliberately later.

Consumer-mode support is stronger than it was before the remediation work, but it is still not a blanket promise that every U.S. consumer document type or jurisdiction-specific rule is covered automatically. Teams still need document-type and policy review before turning on sensitive or excluded use cases.