Sliick Docs E-Signature: Setup and User Guide

Sliick Docs sends documents for electronic signature without leaving Salesforce. There is no separate signing subscription, no per-envelope fee, and no copy of your documents on anyone else’s servers: the signing surface runs on your own org, and the signing record stays there.

This guide covers the whole thing, in the order you will need it:

1. What you get
2. Part 1: One-time org setup
3. Part 2: Settings worth setting
4. Part 3: Sending a document for signature
5. Part 4: What the signer sees
6. Part 5: Tracking and managing a request
7. Part 6: Verifying a signed document
8. Part 7: Troubleshooting

Current for Sliick Docs v2.7. This guide was split out of the Sliick Docs Complete User Guide, which now covers document generation, templates, batches, and bundles. For the legal background behind any of this, see E-Signature in Sliick Docs: The Story, the Law, and the Tick.

Not legal advice. Sliick Docs supplies the signing method and the evidence. Whether an electronically signed document is valid depends on your jurisdiction and your document type. Some categories, including wills, powers of attorney, statutory declarations, and certain property and court documents, are excluded or carry special witnessing rules. Take your own legal advice before enabling e-signature for a document type.

What you get

• Send from any record. Pick a document Sliick Docs generated, an existing PDF on the record, or upload one. Place signature and form fields on it, choose who signs and in what order, and send.
• A signing experience on your own site. Signers open a link, verify themselves with an emailed one-time code, accept a versioned consent statement, and sign. No login, no account, no software.
• Evidence built to be challenged. Every action is written to a tamper-evident, hash-chained event log, re-checked nightly against both the log and the stored files. A Certificate of Completion records who signed, when, from where, and against which consent wording, and refuses to issue if the evidence does not verify.
• Verification by anyone. A counterparty holding the signed PDF can confirm it on a public page with no login and no access to your org.

Part 1: One-time org setup

Seven steps, done once per org, one of which is optional. Budget an hour the first time, most of which is the signing site.

Step 1: Permission sets

• Senders need Sliick Docs User (or Sliick Docs Admin).
• Admins configuring any of the below need Sliick Docs Admin.
• The signer permission set ships with the package and gets assigned to your signing site’s guest user 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. 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. Leave the component’s signing-token property blank: it reads the token from the page URL. Keep the page public.
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, so without this the signing page loads but no document ever appears. The exact checkbox wording moves between Salesforce releases; it is the guest-user 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 to the guest user. From the site’s Administration, then Guest User Profile, then View Users, open the guest user and add the Sliick Docs Signer Guest permission set. Assign the permission set, not a permission set group: Salesforce does not allow groups on guest users.

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

On the Sliick Docs Settings page:

• 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.
• From address. This one is easy to skip and it will bite you. Create and verify an Org-Wide Email Address in Salesforce, then select 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 email on behalf of a guest. On the Org-Wide Email Address itself, allow all profiles, or include the site guest user’s profile.

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, from Setup, then Developer Console, then Debug, then Open Execute Anonymous Window:

Sliick.DocSignChainVerifier.scheduleNightly();

Each night this re-verifies every signature request’s event chain, re-hashes the stored source and signed documents against the digests recorded 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 don’t have to wait for the nightly sweep to get an answer - see On-demand verification in Part 6.

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 (opportunities, accounts, 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.

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 - a tab of its own, alongside Block, Page, and Template, rather than a section at the bottom of the 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.

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

An Experience site serves the component bundle it was last published with. So after any upgrade that touches the signing page, your signers keep running the previous version until you republish. This is the same step you already take after deploying signer components by hand, and a package upgrade replaces the same components.

This is not cosmetic. On a real upgrade, an envelope signed before the site was republished recorded no signer IP address on its Certificate of Completion; the next one, sent after republishing, recorded it correctly. A certificate cannot be reissued, so that envelope keeps a blank address permanently.

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

Part 2: Settings worth setting

All of these live on the Sliick Docs Settings page and all of them have sensible defaults, so you can send your first document without touching any of them. These are the ones worth a decision before you go live.

The signing window

Every signing link expires. The default is 2 days, set org-wide, and a sender can override it for a single request from the send composer. An expired link is refused, reminders are refused on an expired request, and the nightly sweep moves lapsed requests to Expired.

Automatic reminders

Reminders are manual until you turn this on. Enter a schedule as a comma-separated list of ascending whole days, up to six entries, for example 3,7,14. Every signer who has not signed or declined is then reminded on those days after they were invited.

• Blank means off, and no upgrade will ever turn it on for you.
• Offsets count from each signer’s own invitation, so in a sequential request a later group gets its own clean schedule rather than a burst of back-dated reminders.
• Several missed offsets collapse into one catch-up reminder, never a burst.
• Reminders stop at expiry, skip anyone who has signed or declined, and never collide with a reminder you sent by hand.
• A signer part-way through signing is skipped and reminded once they are idle.
• Before it switches on, you are told how many requests are currently waiting on a signer, so the first run’s volume is not a surprise.

Who can turn it on. The hourly job runs with the permissions of whoever saves the schedule, and it has to reach every open request in the org. So starting or widening a schedule requires that person to hold the Sliick Docs Admin permission set plus org-wide reach over signature requests. Sliick Docs Admin already grants that reach, so in practice assigning the permission set is all it takes. A System Administrator profile on its own is not enough: it does not grant the field-level access the job needs.

Turning reminders off, or sending fewer of them, never requires any of this, so an admin who has lost access can always switch it off.

Use a service account. A scheduled job in Salesforce belongs to whoever scheduled it, on any product. If that person is later deactivated, reminders quietly stop while the setting still reads as on. Two things follow:

• Prefer saving the schedule while logged in as a durable service or operations account, using Log in as. A service account does not get deactivated when somebody leaves.
• If an owner is deactivated anyway, the fix is one save: any admin opens Settings and saves the reminder schedule, and Sliick Docs removes the dead job and re-creates it under whoever saved. A schedule whose owner is still active is left completely alone, so an unrelated settings save never disturbs a working job.

The settings page names the user the sweep runs as, and flags an inactive one.

Signing emails: wording and branding

Four email types are yours to edit: invite, reminder, cancellation, and completion. For each you can set a subject and body, using merge tags for the document name, the sender’s name, the recipient’s name, the expiry, your per-send personal message, and the request’s short reference code.

The built-in defaults lead with the document name and the sender’s name rather than an internal record number, and that is deliberate: a recipient deciding whether an unexpected email is genuine needs a name they recognise. An internal reference where a name should be reads as phishing. Write your own copy the same way.

What you cannot change, by design: the signing link, the expiry line, and the anti-phishing footer are always appended automatically after your body text, so no customisation can move, hide, or spoof them. The verification-code email is fixed and stays minimal.

Branding. Add your organisation’s name, an accent colour, and a logo. Supply the logo either by uploading a file or by pasting the address of an image you already host. Every logo you upload is kept in a small library, so you can switch back to an earlier one without re-uploading, and emails already sent keep the logo they were sent with. Use the preview panel and the send-me-a-test-email button before going live.

Retention and legal hold

There are two retention windows and they never mix. Which one governs a request is decided when it is sent and frozen onto it, so deleting a template later cannot change the policy of requests already sent from it.

• Requests sent from a template are governed by that template’s own signature retention window. The default is to keep files forever.
• Requests sent without a template, meaning every picked or uploaded PDF, are governed by an organisation-level window on the Settings page. The default is to keep files forever. It applies only to template-less requests: it is never a floor, a ceiling, or an override for a template’s own value.

When a window elapses, the nightly sweep permanently deletes the Certificate of Completion and the signed PDFs. The request itself, including participants, captured values, and the tamper-evident event chain, is preserved as the retained signing record.

Because deletion is permanent, turning a window on or shortening one asks you to confirm and tells you how many requests become eligible immediately. Retention is measured from the completion date, so switching it on in an org with a backlog clears that backlog on the first nightly run rather than gradually. Raising a window, or setting it back to keep-forever, needs no confirmation.

Legal hold is a flag on an individual request. The sweep skips a held request entirely until you untick it.

Signing tiers: the signature seal

By default a completed document carries the visual signature stamp and the Certificate of Completion, which is the tamper-evident evidence record living in your org. That is the free, native behaviour, it needs no infrastructure and no connection to anything, and for most documents it is the right answer.

Organisations that need the signed PDF itself to carry a cryptographic seal, so it opens as certified in a standard PDF reader, choose a different Signature mode on the Settings page. The choices are:

Everything above Tier 0 is provisioned per organisation, not toggled. There is real certificate infrastructure behind each of them, so choosing one in Settings does not turn it on: saving is refused, with a message naming the mode and pointing you at us, until your org is provisioned. That is deliberate. It means a seal mode is never in effect before the certificate behind it is live. Tiers 1 to 4 also depend on the org being connected to the rendering service. Get in touch if a sealed tier is relevant to you.

If a seal cannot be produced immediately, delivery waits for it. On a sealed tier the completion copy sent to recipients is the sealed PDF. If sealing does not succeed on the first attempt, delivery is held and retried automatically for about an hour, and the request shows Sealing - delivery pending on the Sign Requests card. The copy goes out on its own once sealing succeeds. If it still cannot be produced after the retry window, the request shows Sealing failed - retry, the sender is emailed, and a Retry sealing row action restarts the attempts.

Which tier an envelope was sent under is frozen onto it at send, so changing the org’s Signature mode later never re-writes what an envelope already in flight will produce.

Part 3: Sending a document for signature

Start the request

From the Sign Requests card on the record, choose New signature request. Then pick the document:

• a document Sliick Docs generated from a template on this record,
• an existing PDF already on the record, or
• a PDF you upload now.

A password-protected or dynamic form PDF is refused as soon as you pick it, with advice to remove the password or flatten the form. Documents generated from a Sliick Docs template can never be either shape.

Choose the signers

Each row on the roster offers the people the record already knows: the record itself when it is a person, whoever it looks up to, its owner, and the contacts hanging off it. Pick one, or type in anybody else. A counterparty who is not in your CRM at all is a perfectly normal signer.

Picking someone rather than typing them does two useful things: it removes the chance of a mistyped address, which fails silently and quietly, and it links the completed request back to that contact so signing history becomes reportable.

Signing order. With two or more signers you get a Sign in order toggle. On, only the next signer is emailed, and each one is invited automatically as the previous completes. Off, everyone is invited at once.

In-person signing. Tick Signs in person on a signer and they skip the emailed verification code entirely: you are attesting to their identity, and that waiver is recorded in the audit trail. They receive no invitation email. Instead, after you send, start their hosted signing session from the confirmation panel or from the Sign Requests card. A fresh one-time link opens in a new tab for you to hand the device over. Starting a session is itself recorded, carrying your identity as the host.

Place the fields

Drag field types onto the document and assign each one to a specific signer, colour-coded. Available types are signature, initials, date signed (stamped automatically), date picked by the signer, text, amount, checkbox, and dropdown. Any field can be marked required.

For a dropdown, select the placed field and enter one choice per line. The signer must pick one of your values, and anything else is rejected. A dropdown with no choices cannot be completed, and warns you.

If you place no fields at all, each signer simply gets one signature field at the end of the document.

Fields belong to the signer, not to their row. Reordering the roster moves people around without ever handing one person’s fields to another. Removing a signer takes their fields with them, which is the right behaviour and also a destructive one, so you are asked to confirm first, told who you are removing and how many of their fields go with them.

You can open the email preview and come back without losing placements: the composer keeps your placed fields as you left them.

Add a message

The composer has an optional email panel: a subject prefilled from your invite template that you can override for this one request, and a personal message to the signers. Both are saved with a draft and restored when you reopen it.

Large documents

Two ceilings apply, depending on how your org signs:

They differ because the work happens in different places. On the free path the signer’s own browser holds the whole document and composites their signature onto it locally, so the ceiling is what one browser round trip can carry. On a sealed tier the signer is shown server-rendered pages one at a time and the signed copy is assembled off-platform, so size stops being the binding constraint and page count becomes one instead.

The composer tells you which limit applies to your org rather than letting you find out at send. The limit is checked when you pick the document and again at send, so if your plan lapses between drafting an envelope and sending it, a large document drafted under the higher ceiling is refused at send against the free number. That is better than inviting signers to a document their browsers cannot open.

Placing fields on a document over about 4 MB works slightly differently: the composer lays your fields over server-rendered pages, at true page size, rather than over the file itself. Those pages are prepared against a saved draft, so add your signers, save the draft, and reopen it. Preparation takes a few seconds for a short document and up to about a minute at the page limit. Abandoned drafts have their prepared pages cleaned up automatically.

Part 4: What the signer sees

1. An email naming the document and the sender, with a signing button, the expiry, and an anti-phishing footer.
2. Identity verification. They enter a one-time code emailed to their address. Before they verify, the page shows nothing but a masked name. The code expires in minutes, has a limited number of attempts, and a cooldown between re-issues.
3. Consent. A versioned consent statement appropriate to their country, which they accept with a tick box before signing. The exact wording they accepted is captured at that moment, so editing your consent text later never changes what an old certificate reprints.
4. The document. They page through every document in the request, are moved on to the next one still needing something from them, and see only the fields belonging to what is on screen. In a sequential request, marks already made by earlier signers are shown.
5. Signing. A Start action begins their walk through everything they have to complete. Previous field and Next field move between what is left, a running count (“3 of 7 required”) tracks progress, and it reads All required fields complete once nothing remains outstanding. Reaching the end carries them to the consent checkbox and Sign and finish, rather than leaving them to hunt for it. They draw or type a signature, fill any other fields, and submit; required fields gate submission.
6. Their copy. They can download the signed documents and the Certificate of Completion, either as one archive or as separate files.

If a signer cannot open a document, they are told so in plain words, the request refuses rather than silently wedging, and the problem is reported back to you on the record.

Part 5: Tracking and managing a request

Everything below lives on the Sign Requests card on the source record.

Statuses

Draft (not sent yet), Sent and In Progress (awaiting signatures), Completed, Declined, Cancelled, and Expired.

Actions

• Remind a pending signer by hand, on top of any automatic schedule. There is a throttle so an automatic and a manual reminder cannot both land at once.
• Cancel a request. Every participant’s link stops working and the cancellation is recorded in the event chain.
• Duplicate and resend an expired, cancelled, completed, or declined request. You get a new draft carrying the same documents, field placements, roster, routing, and message, with a fresh signing window and none of the original’s signatures or history. The original is never touched. If anyone had already signed it you are warned first, because a duplicate always starts everybody unsigned.
• Change document, on a draft only. Either regenerate from current record data, which is the fast path when you are resending because the numbers moved, or attach a different file. Either way any field placements already made are cleared, because a placement is pinned to an exact position on a specific page and carrying it to a different file risks a signature landing over the wrong clause.
• Reset verification for a signer who has locked themselves out of the code check. The lockout is a brute-force guard, so it is never cleared as a side effect of a resend: it takes this deliberate act by you. The locked-out state is visible on the card so you know to act.

A blocked signer

If a signer’s browser cannot open one of the documents, the card shows which document and what to do about it. The request stays valid, signable, cancellable, and reminded, because a blocked document is a condition to fix rather than a status to manage.

Downloads and the certificate

Once a request completes, both you and the signer can download everything. Download all gives you one archive containing every signed document plus the Certificate of Completion, named after the documents. The files inside are byte-for-byte identical to the originals. Individual files and a single combined PDF are also available.

The Certificate of Completion records the sender, every signer, the times, the locations, the consent wording accepted and its version, and the full event history. It will not generate over a request whose event chain fails verification, because a certificate over tampered evidence would be worse than no certificate.

Every signed page also carries a short reference code, printed in the header and the margin and repeated on the certificate and in the emails, so any page of any copy can be matched back to the request it belongs to. It is a reference rather than a password and is safe to read aloud to support.

Part 6: Verifying a signed document

On-demand verification

The nightly sweep (Step 4) 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 (the event hash-chain) and Signed documents (the artifact digests), each 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.

Public verification

If you published the verification page in Step 6, 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.

Part 7: Troubleshooting

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 sends in the signer’s context and cannot. Create and verify an Org-Wide Email Address, allow the guest profile on it, and select it on the Settings page. See Step 3.

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. See Step 2.

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 bundle it was last published with, and the browser caches that bundle again on top.

The Certificate of Completion shows no IP address for the signer. Before v2.7, an installed org captured no signer address at all: the signer’s browser asked for it at an address that only resolved in our own development orgs. It is resolved by the server now, so upgrade to v2.7 and republish the signing site. Certificates already issued cannot be reissued, so affected envelopes keep a blank address permanently.

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.

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.

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 eventually sends that fallback so recipients are not left waiting.

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.

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 Part 2.

A deployment is refused because a schedulable class has jobs pending. Clear the reminder schedule, deploy, then set it again. Or allow deployments with Apex jobs in Setup, under Deployment Settings.

Further reading

• Sliick Docs Complete User Guide - templates, generation, batches, bundles, and everything that is not signing.
• E-Signature in Sliick Docs: The Story, the Law, and the Tick - how this maps to electronic signature law, and what the cryptographic seal actually is.
• Sliick Docs v2.6 release announcement - signer field navigation and on-demand integrity verification.
• Sliick Docs v2.5 release announcement - automatic reminders, picking signers from the record, and multi-document signing.
• Sliick Docs v2.4 release announcement - public document verification and the Certificate of Completion.
• Sliick Docs product page - feature overview and AppExchange install link.

If you would like a hand standing up the signing site or working through whether e-signature suits your document types, get in touch.