Sliick Docs v2.9: Confidence at Every Step

Sliick Docs v2.6 was about the documents themselves: combining them, starting them faster, and trusting what they would look like. v2.9 is about confidence in what happens next. Signers can see where they are and what is left. Senders find out the moment a request stops moving. Admins are told when a generated document is missing something, rather than finding out from a customer.

This article gives a high-level overview of what has changed since v2.6. For the step-by-step reference, see the Sliick Docs documentation and the E-Signature guide.

A signing page built around the signer

The signing page has been redesigned so the thing a signer needs to do is never below the fold. A bar at the top carries the document name, progress, and the primary action, and stays put as they scroll. Any notice that matters, such as a reason they cannot finish yet, sits directly beneath it. On a desktop, a rail down the side lists every page and what is still owed on it. On a phone, the same list opens as a sheet from the bottom.

Signing itself is one clear act. The signature pad is labelled Add your signature, with Draw and Type tabs. Finish opens a final step that shows the consent statement and anything still holding the request, and the single binding action is Sign.

Long documents no longer look stuck. Signers see the pages being prepared, with a count and a progress bar, and can start reading as soon as the first page is ready. Scanned PDFs, which could previously appear blank, now render for both the sender placing fields and the signer.

Two smaller courtesies: dates a signer types or picks are shown and signed in one consistent format, and the whole signing experience is available in ten languages.

Your brand, and nothing else, before verification

Until a signer has entered their verification code, the signing page now shows only your organisation’s logo and accent colour, taken from your existing e-signature branding, and names the act they are about to perform. It does not show the document’s title or the signer’s name until the code is entered. A signing link that has been forwarded or copied reveals nothing about what it opens.

The signing and verification pages also carry a brand mark you choose in Experience Builder: None, Logo, or Text. Nothing shows until you opt in, so an upgrade changes nothing on its own, and you can make a different choice for the signing page and the public verification page.

Consent wording that is yours

You can now write your own signer consent statement and sender warning in Settings. Leave either blank and the built-in wording is used. Write your own and the certificate records it as your organisation’s wording. The editor offers machine-translated starting points in ten languages for you to review and adjust before saving; nothing reaches a signer until you save it.

There is now one built-in consent statement for every signer, wherever they are. It records the signer’s intent to sign rather than asserting a legal outcome, and it tells any signer whose document needs a witness, notarisation, or wet ink not to sign and to ask the sender. Organisations that need particular statutes named write their own wording.

Each signer’s consent wording is frozen at the moment they are invited. What they are shown, what they accept, and what the Certificate of Completion records are the same text. Requests sent before this release keep the wording they were sent with.

Sending is faster, and a document from anywhere can be signed

Pick any PDF on the record in Send for Signature. If it was generated from a template with e-signature configured, the signature fields and signers are placed for you, with no extra step and no re-render. The document you picked is exactly the document that gets signed. A file with no placement information opens for manual placement as before, so sending a counterparty’s contract remains straightforward.

Documents that come from other systems can carry signature tags. Write {{@Signature:Role:Order:Type}} where each field belongs, in a Word document or any PDF, and the composer places the fields and builds the signer list. Documents carrying DocuSign-style anchors or Adobe Acrobat Sign text tags are read as well, so templates built for those products keep working. Anything placed from a tag can be moved or removed before sending.

The composer now has one document picker for every PDF on the record, and a template tab that generates a fresh, saved document and hands it straight to placement. Placing your first field creates its signer role, and removing a signer who owns fields asks you first.

You are told when a request stops moving

If a signing invitation or a verification code cannot be emailed, the request’s card on the record now says so: which signer is stuck, what it means, and the one action that recovers it. The request stays open, still signable, and the scheduled reminder is the recovery, because the signers already hold live links. A signer whose code could not be sent loses nothing and can simply try again.

Every e-signature email to a recipient now carries a reply address pointing at the person who sent the request, so a signer with a question reaches a human instead of a shared mailbox that discards replies. This means the sender’s own email address is visible to recipients. If your team sends from a shared login, send from a monitored account or set the request’s Sender field before sending.

The address you send from is now something you can see and choose. E-sign from address in Settings lists the organisation-wide addresses signing email can be sent from, and Currently sending as shows the identity that will actually be used, marked as inherited when you have not chosen one.

Verified before download

A signed document, its completion package, and its Certificate of Completion can now only be downloaded by a signer who has verified their identity with their code. Previously a signing link alone was enough. This is a security fix and applies immediately.

The signer’s location is recorded on every certificate, a signer’s name in Chinese, Japanese, or Korean renders correctly, and the certificate’s summary and audit log always agree with each other.

Barcodes that scan

Every barcode now scans. Some values previously produced a symbol a scanner would reject, a symbol wider than its box was cut off at the edge, QR codes carrying long values such as tracking links or payment payloads were malformed, and barcodes in Word output could lose bars. All of these are fixed.

Barcodes also print their value in readable text underneath, on by default and switchable per block, so a number can always be recovered by hand. Instead of asking you for a width, a barcode block now takes a scan quality: Compact, Standard, or Rugged. The width follows from the data. If a value is too long to scan in the space available, the editor says so and names the fix: widen the block or shorten the value. Barcodes render in running headers and footers, and in Word-file templates.

Anything already published keeps its current output until you republish it. A barcode that scanned before still scans.

A document tells you when something is missing

A merge field that could not be filled, because it was renamed, deleted, or the person generating cannot read it, used to leave a silent blank in a document marked as succeeded. It is now named in the generation’s warnings. A field that exists and is simply empty on the record stays silent, because that is data, not a mistake.

Merge fields inside callouts and list items are checked at publish like any other, so a draft naming a field that does not exist is caught before it ships. When a barcode cannot fit or a cloud image falls back to a note, the generation history now says so.

Preview is more honest too. A repeat shows the real rows the document will contain, respects the repeat’s filter, and explains why a repeat is empty rather than just saying “no rows”. Repeat rows now print in a defined order, oldest first, in both the preview and the document. If a template’s repeat currently prints rows in an order you rely on, generate one document and check it before rolling out.

Smaller improvements worth knowing about

• Chinese, Japanese, and Korean text renders in generated PDFs, on every template, with no republish needed.
• A new “Whole number” format drops the trailing .00 from quantities, in designed and Word-file templates alike.
• Proofs and previews honour a template’s theme override, so the proof you approve is what the template publishes.
• A published template’s Source Type and Base Object can no longer be changed, because either change would break every future generation. The save is refused with an explanation.
• Duplicating a template copies everything: source type, header and footer content, watermark, folder, file-name pattern, and auto-email settings.
• Word-file templates start new versions from Word. Upload a new file or attach one from the Word add-in.
• Nested conditional blocks in Word-file templates merge correctly, and a structurally broken template is refused at upload with the tag and where it is.
• Settings pages have a section rail down the left, so you can jump straight to a card.
• The open-source Sliick Charts package can be installed alongside Sliick Docs.
• A Flow cannot generate a download-only template, and is told so up front rather than losing the document.
• The record-page generator loads for every user, including those with only the basic permission set.
• The two settings e-signature needs are checked before a send, and named on the composer with the exact field to fill in.

Upgrading

Sliick Docs v2.9 is live on the AppExchange. New installs get v2.9 directly.

• Republish your signing Experience site after upgrading. The site keeps serving the previous signing page until you do, and on this release that affects what a signer is told. One republish resolves it.
• Two settings are now required before a send: a signing page address, and an organisation-wide email address that is allowed for all profiles. An organisation that never configured these will find Send refused until they are filled in. Drafts stay creatable and editable in the meantime, and requests already sent are unaffected.
• Documents generated before this release keep manual placement. Regenerate a document to get automatic field placement.
• Published templates keep their current output until republished. Barcode and Word-template fixes take effect on the next publish. Templates with a theme override will show “proof is stale” once; one re-proof clears it.
• Check repeat row order on any template that relied on the previous order.
• Everything else carries forward unchanged. Templates, bundles, batches, branding, and settings continue to work exactly as before.

Where to start

• Sliick Docs documentation - the full reference.
• E-Signature guide - setup, sending, tracking, and verification.
• Sliick Docs v2.6 - real PDF merging, the starter gallery, and an editor that matches the page.
• Sliick Docs product page - feature overview and AppExchange install link.

If you would like a hand rolling out the new signing page, writing your own consent wording, or bringing signature tags into documents from other systems, get in touch.