One-time org setup

Seven steps, done once per org, one of which is optional. Budget an hour the first time; most of it is the signing site. You need Sliick_Docs_Admin to do any of this.

Step 1: Permission sets

• Senders need Sliick Docs User or Sliick Docs Admin.
• Admins configuring anything below need Sliick Docs Admin.
• The signer permission set ships with the package and gets assigned to your signing site in Step 2. You do not assign it to people.

Step 2: Stand up the signing site

The page your signers land on is a public page you host in your own org. Salesforce does not allow Experience Cloud sites to be packaged, so this is a one-time build. The signing component itself ships in the package: you drop it on a page and point Sliick Docs at that page.

1. Create the site. Go to Setup, then Digital Experiences, then All Sites, then New. Choose Build Your Own (LWR), give it a name and a URL path such as esign.

2. Build the signing page. Open the site in Experience Builder, add a new standard page, set its route to /sign, and drag the Sliick Docs Signer Canvas component onto it. Keep the page public.

   Two component properties are worth knowing:

   • Signing token. Leave it empty. The page reads the token from the link in each signer’s invitation email. A value typed here overrides that link for every visitor and pins the page to one participant’s envelope. While you are placing the component in Experience Builder there is no link and therefore no token, so the page simply reads eSignature and points a visitor at their invitation email. That is what you should expect to see, and it is what somebody who reaches the page without a link sees too.
   • Brand mark. Choose None, Logo or Text. None is the default, so the page shows no brand mark until you opt in. Logo shows the e-sign logo you uploaded in Settings; Text shows your brand name in words. Either way the accent colour comes from your e-signature branding, so the page matches the invitation email. The property is set per placement, so your signing page and your public verification page can carry different marks.

3. Enable guest file access. In Experience Workspaces, under Administration, then Preferences, turn on guest access to files and records. Signers open the document as the site’s guest user profile, so without this the signing page loads but no document ever appears. The exact checkbox wording moves between Salesforce releases; it is the guest file and record access preference for the site.

4. Publish and activate. Publish in Experience Builder, then activate the site under Administration so its status is Live.

5. Assign the signer permission set. From the site’s Administration, then Guest User Profile, then View Users, open the user listed there and add the Sliick Docs Signer Guest permission set. Assign the permission set, not a permission set group: Salesforce does not allow groups here.

Step 3: Point Sliick Docs at the site, and set a from address

These two settings are the ones Sliick Docs checks before it will send anything for signature. Both live on the Sliick Docs Settings page, neither has a working default, and a send is refused with a banner naming the missing one rather than going out and failing quietly at the signer’s end. Drafts stay creatable and editable while you fill them in.

• Signer surface URL. The full address of the signing page you just built, which is the site base plus your route, for example https://acme.my.site.com/esign/sign. Until you set it, Send is refused, because an invitation with no page to open is worse than no invitation.
• E-sign from address. Create and verify an Org-Wide Email Address in Salesforce, tick Allow All Profiles on it, then pick it here. Invitation emails can fall back to the sending user, but the identity-verification code is sent in the signer’s own context, and Salesforce will not send that email from a public site unless an org-wide address allows it. An address that is verified but restricted to selected profiles is named as the reason the check has not passed, rather than being silently ignored. An address still waiting for its verification email is flagged on the send composer without blocking the send.

Picking the identity signers see. E-sign from address is a picker over the org-wide addresses signing email can actually be sent from, each shown as Display Name <address>, which is the form a recipient’s inbox shows. Underneath it, Currently sending as reports the identity e-signature will actually use, marked inherited when you have not chosen one and the alphabetical default applied. An org with accounts@, noreply@ and support@ sends every signature request from the first of those unless you say otherwise, so it is worth a look even if you never change it.

The display name itself belongs to the address in Setup and can only be changed there, so the card links straight to it. If you cannot read that Setup object, you are told exactly that: the object is named, your setting still saves, and the message does not claim e-signature is broken, because it may well be sending perfectly.

The classic symptom of a missing from address: the invitation email arrives fine, and the verification code never does.

Step 4: Schedule the nightly integrity check

Run this once, as a user holding Sliick Docs Admin. Go to Setup, then Developer Console, then Debug, then Open Execute Anonymous Window, and run:

Sliick.DocSignChainVerifier.scheduleNightly();

Each night this re-verifies every signature request’s event chain, re-checks the stored source and signed documents against the record of them in that chain, and raises a Salesforce notification if anything fails to verify. A clean sweep is silent, so no news is good news.

You do not have to wait for the nightly sweep to get an answer: see Verification and certificates.

Retention needs nothing extra scheduled: it rides the document retention sweep you already have.

Step 5: Add the components to your record pages

In Lightning App Builder:

• Sign Requests on the records you send from, such as opportunities, accounts, or whatever your agreements hang off. This is where senders start a request and manage everything afterwards.
• Signature Envelope Artifacts on the Doc Signature Request record page, so senders can download the certificate and the signed documents from the request itself.

Step 6 (optional): Publish the public verification page

If you want counterparties to be able to verify signed documents themselves, add the Document Verifier component to a published page on an Experience site, then set Verifier surface URL on the Settings page. Anyone holding a signed PDF can then confirm it there with no login. The file is fingerprinted in their browser and never uploaded to you.

This component carries the same Brand mark property as the signing page: None, Logo or Text, defaulting to None, with the accent colour taken from your e-signature branding. Because it is set per placement, a public verification page can carry your brand name in words while the signing page carries your logo, or the other way around.

Step 7: Turn e-signature on for a template

E-signature is off on every template until an admin turns it on, from the E-sign tab in the Template Editor’s right rail. Enabling it shows a versioned warning about document categories that are excluded or restricted for electronic signing, and records who acknowledged it and when. That acknowledgment is snapshotted onto every request sent from the template. If the warning text is ever updated, templates acknowledged against the older version will ask for re-acknowledgment. The warning is the packaged wording unless you have written your own: see Consent and sender wording.

On the same tab you define signer roles and place the fields each role fills in. Roles are placeholders: real people are matched to them at send time, and a role mapped to a record field fills itself in automatically.

Sending an existing or uploaded PDF needs no template and therefore has no template opt-in behind it. For those sends, the sender’s own authorisation acknowledgment in the send composer is the record, and the system will not send without it.

After every upgrade: republish the signing site

Republish your signing site after every upgrade, before you send anything. An Experience site serves the page it was last published with, so until you republish, your signers keep opening the version of the signing page that shipped with your previous release, even though the rest of the org has moved on.

This is not cosmetic. A signing page left unrepublished can tell a signer something untrue: that a verification code has been sent, for instance, when it could not be emailed at all, leaving them waiting for a code that will never arrive. It can also mean details the certificate expects, such as the signer’s location, are never captured. A Certificate of Completion cannot be reissued, so an envelope signed against a stale page keeps whatever gaps it recorded, permanently.

Republish first, then send. If a signer still sees the old behaviour afterwards, have them reload the page: a browser caches the page separately from the site. Nothing else about signing is affected, and the signature itself completes either way.