E-signature setup#

Built-in signing needs a one-time administrator setup before the first signature request: a public site that serves the signing pages, a verified sender address, the guest permission set, and e-mail deliverability. The Signature Settings tab in the Command Hub shows every item as pass/fail with a fix link, so you always know what is left.

Note

Nothing here is needed for document generation alone. Skip this page for clients who do not sign.

The checklist#

#	Requirement	Where
1	An active Salesforce Site or Experience Cloud site	Setup → Sites, or Digital Experiences
2	The signature Visualforce pages added to that site	Site → Site Visualforce Pages
3	Site URL saved in Signature Settings — the base URL only, no trailing `/s`	Command Hub → Signature Settings
4	Welisa Guest Signature assigned to the site's guest user	Site → Public Access Settings → View Users
5	A verified Org-Wide Email Address with Allow All Profiles, selected as Send Emails From	Setup → Organization-Wide Addresses; Signature Settings
6	Email Deliverability = All email	Setup → Email → Deliverability
7	DKIM for the sending domain	Setup → Email → DKIM Keys + DNS
8	Experience Cloud only: guest file access preference enabled	Site → Workspaces → Administration → Preferences
9	Content Deliveries and Public Links enabled (needed for shared-asset logos in e-mails)	Setup → Content Deliveries and Public Links

1–3. The signing site#

Signers are external people without a Salesforce login, so the signing pages run on a public site as a guest user.

Create or pick a site. A classic Salesforce Site (*.my.salesforce-sites.com) is the simplest; an Experience Cloud site (Aura or LWR) works too. Find the domain with SELECT Domain.Domain, Site.Name, PathPrefix FROM DomainSite.
Add the pages to the site. Site → Site Visualforce Pages → add DocGenSignaturePdf, DocGenSignature, DocGenVerify and DocGenSign (and the Aura apps DocGenVerifyApp and DocGenSignOut if listed). If you ever switch which site serves signing, re-add the pages to the new site — they do not carry over.
Save the Site URL in Command Hub → Signature Settings: this org's site base URL only. Copying an Experience Cloud URL from the browser usually appends /s (for example https://acme.my.site.com/signing/s); with it, every signing link opens to "Invalid page". Remove the /s. Custom branded domains work once the /s is gone.

Warning

A sandbox created from production, or a partial copy, carries the source org's Site URL. Always set this org's own URL — signing links otherwise point at another org and return "Page Not Found".

4. The guest permission set#

Salesforce hides the guest user behind several clicks:

Setup → Sites → click your e-signature site's name.
Public Access Settings — opens the site profile.
View Users → select the site guest user.
On the user record, Permission Set Assignments → Edit Assignments → add Welisa Guest Signature.

Each site has its own guest user; assignments do not carry over between sites. The guest user is never granted create, update or delete on package objects: guest writes are authorised by the signer's cryptographic token, not by permissions.

5–7. E-mail: sender address, deliverability, DKIM#

Signature invitations, PIN codes, reminders and completion notices are sent by Apex, often from the guest context, which cannot send as itself. Three gates:

Org-Wide Email Address (OWA). Setup → Organization-Wide Addresses → create the address the client wants signers to see, verify it (green check), and enable Allow All Profiles (guest signers trigger the completion e-mail). Then select it as Send Emails From in Signature Settings. Reply-to is set automatically to the request creator.
Deliverability. Setup → Email → Deliverability → Access to Send Email = All email. Sandboxes default to System email only, which silently drops every application e-mail (NO_SINGLE_MAIL_PERMISSION in the error log).
DKIM. Setup → Email → DKIM Keys → create and activate a key for the sending domain, publish the CNAME records in DNS. Salesforce blocks unauthenticated sends from custom domains. Also make sure the domain's SPF record includes include:_spf.salesforce.com and that DMARC is not p=reject without alignment.

Without these, signing still works but e-mails do not deliver; the reason is logged on the request's Email Status field.

8. Experience Cloud: guest file access#

Only for Experience Cloud sites: your site → Workspaces → Administration → Preferences → tick "Let guest users view asset files, library files, and CMS content available to the site." Without it, signers see "Document unavailable" even though everything else is configured. Classic Salesforce Sites do not need this.

9. Shared assets in e-mails#

Logos referenced from the Asset Library inside e-mail templates are published as public file links. Enable Setup → Content Deliveries and Public Links (all boxes) so those links can be created.

Verify#

Open Command Hub → Signature Settings: every item on the setup checklist shows green. Then send yourself a test request from a record with a signature-ready template (the Agreement starter works) and walk through PIN verification and signing. If anything fails, Troubleshooting lists the checks in order.

What else lives in Signature Settings#

Link expiration (days) — org default for signing links (default 2; individual sends and the Flow action can override, 1–365).
Reminders — enable and enter hour offsets after send (24, 72, 168); a scheduled job runs hourly.
Require Email Verification and Pre-fill Signer Email — org defaults for PIN verification; templates and individual sends can override.
Hide Decline Button — remove the signer's Decline option on every signing page (a template can hide it for itself alone).

E-mail wording, colours and logos are managed on the Email Templates tab; reusable sender identities on the Brands tab. Both are described under E-signatures.