Troubleshooting
Symptoms senders and admins actually hit, with the fix for each. If your problem is with generating a document rather than signing one, see Troubleshooting in the reference section.
Sending
Section titled “Sending”Send is refused with a banner about a missing setting. Sliick Docs checks two things before it will send: a signing page address for signers to open, and an org-wide email address the verification code can come from. The banner names the one that is missing and where to fill it in. Filling it in is the whole fix, and your draft is waiting for you afterwards. See One-time org setup.
The org-wide address is verified, but the check still will not pass. The address is restricted to selected profiles. It has to be allowed for all profiles. The check names this as the reason rather than ignoring the address. An address that is merely still waiting for its verification email is flagged on the composer but does not block the send.
Settings refuses to save a Signature mode. Every tier above Tier 0 is provisioned per organisation, and saving is refused until yours is. The message names the mode. See Signing tiers.
Signers not receiving things
Section titled “Signers not receiving things”The signer got the invitation but no verification code. The org has no usable from address. Invitations send in the sender’s context and work without one; the verification code cannot. Create and verify an Org-Wide Email Address, allow all profiles on it, and select it as the E-sign from address on the Settings page.
A signer says they are waiting for something that never arrived. Check the envelope’s card on the record. If an invitation or a verification code could not be emailed, the card says which signer is affected and what recovers it. The envelope is still open and still signable, and the scheduled reminder is the recovery: the signers involved already hold live links. A verification code that failed to send costs the signer nothing, so their remaining attempts and cooldown are untouched.
Reminders are on but nothing is going out. The schedule’s owning user has probably been deactivated, or has lost the permission set or their envelope access. Any admin saving the reminder schedule re-creates the job under themselves. See Settings.
The signing site
Section titled “The signing site”The signing page loads but no document ever appears. Guest file access is off for the site. Turn on guest access to files and records in Experience Workspaces.
Signers hit an “under construction” page. The site is published but not activated, or not published at all. Both are needed.
Signer-facing changes have not appeared after an upgrade. Republish the Experience site, then have the signer reload the page. The site serves the page it was last published with, and the browser caches that page again on top. This is worth doing promptly rather than when convenient: a signing page left unrepublished can tell a signer a verification code has been sent when it could not be emailed at all.
The signing page shows “eSignature” and points at an invitation email. That is the page opened without a signing link, which is what you see while placing the component in Experience Builder and what a visitor gets if they reach the page directly. It is not a fault. Check that the component’s Signing token property is empty: a value there overrides the link in every signer’s invitation and pins the page to one participant’s envelope.
Completion, certificates and seals
Section titled “Completion, certificates and seals”Everyone signed, but nobody has the final PDF. The final copy is assembled in the last signer’s own browser. If that browser could not complete it, you are emailed immediately, and the request shows an assembly-pending badge with a Finalize signed copies action that re-runs it from your browser. If yours cannot either, you can send a certificate-only package: recipients get the unmarked signed document plus the Certificate of Completion with a plain explanation. The evidence is identical either way. If you never act, a nightly sweep re-nudges you and sends that fallback package automatically after seven days, so recipients are not left waiting. The seven days is fixed and is not a setting you configure.
A signer cannot download their signed copy. Downloading the signed document, the completion package or the certificate requires the signer to have entered their verification code. Holding the link is not enough. If you reset that signer’s verification after the request completed, they are asked to verify again and the download works once they have.
The Certificate of Completion shows no location for the signer. The signing site was not republished after the org was upgraded, so signers were opening a page that could not capture it. Republish the site and the location is recorded on everything signed from then on. A certificate cannot be reissued, so envelopes already signed keep a blank location permanently. See After every upgrade.
The certificate refuses to generate with a chain error. Treat it as an integrity incident rather than a bug. The event chain is tamper-evident and it is telling you something changed. Preserve the request with a legal hold and investigate.
The request says “Sealing failed - retry”. Your org is on a sealed tier and the seal could not be produced within the retry window, so the signed copy is still waiting. Use the Retry sealing action on the Sign Requests card to restart the attempts. If it keeps failing, tell us: the certificate infrastructure behind a sealed tier is ours to fix.
Deployments
Section titled “Deployments”A deployment is refused because a scheduled job is pending. Clear the reminder schedule, deploy, then set it again. Or allow deployments with jobs pending in Setup, under Deployment Settings.