Settings
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 two settings that have no working default, and that a send is refused without, are in One-time org setup.
Each Settings tab lists its sections down the left-hand side. Click one to jump straight to it; the rail stays beside the page afterwards, so you can move between cards without scrolling back. Nothing is hidden behind it: every section is still on the page and can be read top to bottom.
The signing window
Section titled “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
Section titled “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
Section titled “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. The brand-name box shows the name that will actually be sent if you leave it alone, rather than sitting empty and hiding the default. 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.
The same accent colour and logo carry through to the signing page and the public verification page, where a Brand mark property decides whether each page shows nothing, your logo, or your brand name in words.
Retention and legal hold
Section titled “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.
Note: these windows are separate from the retention that deletes generated documents. See Compliance.
Signing tiers: the signature seal
Section titled “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.
| Signature mode | What a completed document carries |
|---|---|
| Tier 0 - Audit trail + Certificate of Completion (default) | The visual stamp and the certificate. No cryptographic seal on the PDF itself. The free, native path. |
| Tier 1 - Self-signed | A structurally valid seal made with a self-signed certificate. For testing only. It behaves exactly like the certified tiers, so it is how you prove the flow out end to end, but PDF readers show “validity unknown” because the certificate is not a trusted one. |
| Tier 2 - Bring your own key | A seal made with your own organisation’s trusted certificate. |
| Tier 3 - Certified seal (AdES), sealed in your organisation’s name | A seal from a trusted certificate authority, applied under your organisation’s verified identity. Documents open as certified and unaltered in standard PDF readers. |
| Tier 4 - Qualified seal (QES, EU) | A qualified electronic seal at eIDAS QES grade for EU-regulated workflows, issued through an accredited trust-service provider after identity verification of your legal entity. |
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.