Verification and certificates

Three separate things prove a signature after the fact: the nightly and on-demand integrity checks, the Certificate of Completion, and the public verification page a counterparty can use without any access to your org.

On-demand verification

The nightly sweep checks every request automatically and only speaks up if something fails. If you need the answer for one request right now, for example while working through a dispute, the Diagnostics tab has a Verify signature integrity action that runs the same two checks immediately:

• Signature records, meaning the event chain.
• Signed documents, meaning the stored files.

Each is reported separately as No issues found or Issues found - check alerts, with a Last verified timestamp and who ran it.

It runs under your own authority as the person asking, rather than as a fixed scheduled user, so the result always means something: a check run by someone with no access to the relevant records would tell you nothing.

What the Certificate of Completion records

The certificate is the document you hand to anyone who asks how a signature was obtained, so it is written to survive being read closely.

• Each signer’s own consent wording. The wording is frozen for a signer at the moment they are invited, and the certificate reprints exactly that text, its version, and when they accepted it. Editing your consent wording afterwards changes nothing about a signature already collected.
• A summary that agrees with its own audit log. The counts in the envelope summary and the events listed underneath describe the same history, so the two halves of the certificate can be read against each other.
• Names as they are actually written. A signer’s name in Chinese, Japanese or Korean prints on the certificate in their own script.
• Where each signature was made from, alongside who signed and when.

A certificate will not generate over a request whose evidence does not verify, because a certificate over evidence that fails its own check would be worse than no certificate at all.

Downloading it requires verification. A signer, like anyone else, must have entered their verification code before they can retrieve the signed document, the completion package or the certificate. If you reset a signer’s verification after completion, they are asked to verify rather than turned away.

Public verification

If you published the verification page during org setup, anyone holding a signed PDF can confirm it themselves: they drop the file onto the page, or paste its fingerprint, and see the document name, the completion date, a masked summary of who signed, and confirmation that the audit chain verified intact.

No login, no Salesforce account, and no access to your org. The file is fingerprinted in the visitor’s own browser and never uploaded to you. What the page reads is a purpose-built, masked public summary and nothing else, so no private signing detail is exposed.

This is worth telling counterparties about. It is frequently what somebody asking for a “properly signed” document actually wants: not a banner in their PDF reader, but a way to satisfy themselves that the document in their hands is the one that was signed.