E-Signature in Sliick Docs: the story, the law, and the tick

TL;DR

• Sliick Docs now has e-signature, built natively into the app you already generate documents from.
• SES, the legal baseline most e-signature tools actually run on (Dropbox Sign, S-Docs, Conga Sign, PandaDoc for Salesforce included, no certificate needed), is Sliick Docs’ free, native tier.
• AES-grade signing (the cryptographic Adobe green tick) is a premium tier we’ve built. QES runs on the same plumbing: bring your own qualified certificate and we’ll wire it in. Want either one? Yes we can! - Get in touch.

How is this legal?

That’s the question I actually asked myself, sitting at my desk, looking at a document my own solicitor had just sent me to sign. The link went to Dropbox Sign, a perfectly reputable company. I opened it, typed my name, ticked a consent box, submitted. Out of habit I checked the finished PDF the way I’d check any signed document: no certificate icon, no padlock, no green banner across the top, nothing that looked remotely cryptographic. Just a name and a timestamp.

My first thought was not generous. Should I change solicitors? My second thought, once I’d calmed down enough to actually look into it, was more useful: is this actually how it’s supposed to work?

Turns out it is, and Dropbox Sign isn’t remotely alone. Go looking on the Salesforce AppExchange itself and most of the day-to-day e-signature options ship exactly the same way by default, S-Docs among them, plus names like Conga Sign and PandaDoc for Salesforce: a visual signature and an audit trail, no embedded certificate, nobody’s contract has fallen over in court for it. I’d absorbed the same assumption most people have, that a “real” e-signature needs a digital certificate behind it, the way a website needs one for HTTPS. It doesn’t. Electronic signature law, in Australia and almost everywhere else, cares about whether the method identifies the signatory, captures their intent, and holds up as reliable evidence afterwards. None of that requires a certificate. It requires a good audit trail.

That was the seed of native e-signature in Sliick Docs. Six months of research and a lot of evenings and weekends of my own sweat, no contractors, no shortcuts, and what came out the other end is full e-signature inside the app you already generate documents from: identity verification, consent capture, a tamper-evident audit chain, retention rules that respect the Privacy Act, no separate product to buy, no envelope fee. It’s rolled out and grown steadily since, and it stays free, on purpose, for reasons I’ll get into below.

But building it taught me something the solicitor story doesn’t cover: plenty of people still want the tick. Not because the law requires it, but because DocuSign spent two decades training the market to expect one. So the second half of this article is about that: what the tick actually is, why it’s real cryptography rather than theatre, and why it’s a genuine premium conversation rather than something we can fold into the free tier.

The disclaimer, up front: this article is general information, not legal advice. Whether an electronically signed document is valid and enforceable depends on your jurisdiction, your document type, and your facts. Consult your own legal counsel before relying on electronic signatures for any document category.

If that paragraph made you wonder whether the product stands behind its own feature, read the next section first.

Every commercial product carries this disclaimer. Every single one.

It’s reasonable to expect an e-signature vendor to just say “our signatures are legally binding, full stop.” None of them do, including the ones whose entire brand is legal enforceability:

• DocuSign publishes per-country “eSignature Legality Guides,” and every one is wrapped in the statement that the content is for general information purposes only and not intended to serve as legal advice, with a recommendation to consult a licensed attorney for specific questions.
• Adobe goes further on its Electronic Signature Laws pages: “Adobe cannot provide legal advice… Any information in this paper is not intended as legal advice and should not serve as a substitute for professional advice,” directing customers to consult an attorney about their specific situation.
• S-Docs, the closest Salesforce-native comparison, carries it contractually rather than editorially: their subscription agreement makes the customer responsible for “the accuracy, quality and legality of their Data” and for using the service in accordance with applicable laws.

This isn’t vendors hedging on a weak product. It reflects something true about the law: electronic signature statutes validate methods, not products. No software can be “compliant” in the abstract, because the same signature that perfectly executes a sales contract is legally void on a will. The vendor controls the method; only you know the document. So the honest division of labour, the one every serious vendor states, is that the product supplies the method and the evidence, and the customer (with their counsel) decides which documents the method suits.

Sliick Docs follows the same convention, in the admin guide and at the moment it matters most: enabling e-signature on a template requires acknowledging a versioned warning about excluded document categories. We didn’t bury the caveat in a terms page; it’s in the click path.

The Australian test, requirement by requirement

Australia’s Electronic Transactions Act (Cth), mirrored by state acts, makes an electronic signature effective when three things hold. Sliick Docs treats each as a functional requirement with a named feature behind it, plus the Privacy Act obligations that follow the signature around afterwards. This is all part of the free, native tier, the same one my solicitor’s tool used.

Requirement 1: a method identifies the signatory and indicates their intention

Requirement 2: the method is as reliable as appropriate for the purpose

This is the requirement most products under-serve, because reliability is invisible until a dispute:

• An append-only, hash-chained audit log. Every envelope event carries a SHA-256 hash chained over the previous event. The package grants no persona any write access to these records, but Salesforce’s Modify All Data privilege sits above any package’s permissions, so a full system administrator could reach them, on this or any other Salesforce e-signature product. The chain is the answer to that residual power: the log is tamper-evident rather than tamper-proof, and an edit or deletion anywhere in the history, by anyone, breaks the chain detectably. I’d rather state that distinction plainly than claim an impossibility the platform doesn’t offer.
• A nightly integrity verifier re-computes every envelope’s chain and alerts admins on any break. It also re-hashes the stored source and signed documents themselves and compares them against the digests recorded in the chain, so a file quietly swapped for a different one is detected, not merely a rewritten log. Evidence that’s never checked is just data.
• Content digests and release pinning. Each document’s SHA-256 digest is recorded at send; the envelope pins the exact template release that produced the attached document, so nothing published later can change what the signer saw. On completion the signed document’s own digest is chained too, which is what gives the nightly artefact check something to compare against.
• A certificate that refuses to lie. The Certificate of Completion won’t generate over an envelope whose chain fails verification. An integrity certificate over tampered evidence would be worse than none.
• Verification by whoever holds the document. A counterparty who receives the signed PDF can confirm it themselves on a public verification page: drop the file in, or paste its fingerprint, and see the document name, the completion date, a masked summary of who signed, and confirmation that the audit chain is intact. No login, no Salesforce account, no access to your org. Reliability only the sender can check is a weaker kind of reliability.

Requirement 3: consent to the electronic method

The signer-side consent capture above covers the signer; proceeding to sign is itself conduct indicating consent, the same posture the incumbents take. On the sender side, the per-template opt-in acknowledgment is the organisation’s own recorded decision that electronic execution suits this document type.

And after the signature: APP 11.2

Privacy obligations don’t end at signing. Australian Privacy Principle 11.2 requires destroying or de-identifying personal information you no longer need, while litigation readiness requires keeping the signing record. Sliick Docs resolves the tension with retention windows: per-template for anything generated from a template, and an organisation-level window covering envelopes sent without one, so an uploaded or picked PDF is governed too rather than kept indefinitely by default. Either way the certificate and stamped files are destroyed on schedule, while the envelope, captured values, and the tamper-evident audit chain survive as the retained signing record. The policy that governs an envelope is fixed at the moment it is sent, so a later change of configuration can’t reach backwards into documents already signed under different terms. Both windows are off until you set them, and enabling or shortening one asks you to confirm exactly what will be destroyed. A legal-hold flag exempts any envelope. And because nothing ever leaves your org on this tier, there’s no second copy on a vendor’s servers for your privacy officer to chase.

How this translates to other jurisdictions

The pleasant surprise of e-signature law is how internationally consistent the baseline tier is. Most of the world legislated from the same two templates, the UNCITRAL Model Law (Australia’s ancestor) and the US approach, so a method built carefully against the Australian test travels well:

• United States (ESIGN Act + UETA): the test is intent to sign, consent to do business electronically, association of the signature with the record, and record retention. Every element maps directly: consent capture, the event chain associating each signature with the exact document digest, and envelope records the sender retains in their own org.
• New Zealand (Contract and Commercial Law Act 2017): essentially the Australian test, identification, intention, and reliability as appropriate to the purpose, with its own excluded-categories list. The same features answer it; the same template-level exclusions discipline applies.
• United Kingdom: common law has long accepted that almost any mark made with intent can sign a contract; UK eIDAS adds the tiered framework below. The baseline tier is comfortably met.
• European Union (eIDAS): eIDAS defines three tiers. Simple electronic signatures (SES), which cannot be denied legal effect merely for being electronic, is the tier native Sliick Docs operates in, and it’s the tier the overwhelming majority of commercial e-signatures worldwide use, whatever the vendor. Advanced (AES) and Qualified (QES) signatures require cryptographic signature-creation data under the signer’s own sole control, certificate-based PKI, which no signature drawn in any web canvas provides, ours or anyone’s, and which the premium tick tier below doesn’t claim either, because the certificate is provisioned to your organisation, not to each individual signer.

Two honest caveats travel with all of this. First, excluded document categories exist in every jurisdiction and they differ, wills, powers of attorney, statutory declarations, family law documents, some property dealings, which is exactly why the per-template acknowledgment exists. Second, the signer page ships in English only. Jurisdictions where consent must be meaningfully understood in another language are not yet supported.

The tick people still ask for

Here’s the tension the solicitor story doesn’t resolve: legal validity and what a signature looks like to the person receiving it are two different things. Everything above satisfies the law. None of it produces the green “Signature Valid” banner Adobe Reader shows on a cryptographically sealed PDF, because native Sliick Docs signatures are a visual stamp plus an audit trail, not an embedded digital signature. For most documents, that’s genuinely fine. But procurement teams, some solicitors, and plenty of counterparties have been trained by two decades of DocuSign to expect the tick specifically, and “the law doesn’t require it” is a true answer that doesn’t always land in a negotiation.

There is a second answer that doesn’t need the tick at all. The public verification page above lets that counterparty check the document against your system directly, which is frequently what they were really after: not a banner, but a way to satisfy themselves the thing in their hands is the thing that was signed. Sometimes, though, the banner is the actual requirement.

So that’s what the last stretch of the six months went into: an actual embedded cryptographic signature (PAdES, the same PDF signing standard behind that Adobe banner) that chains to a certificate on the Adobe Approved Trust List, the same class of trust infrastructure that DocuSign and the other big platforms rely on to mint their own green-tick certificates. Open the signed PDF in Acrobat and it shows exactly what a DocuSign or Adobe Sign document shows: signed, valid, trusted.

That is the actual panel, on an actual signed document. Four things in it are worth reading separately, because each one is a different claim: the source of trust is the Adobe Approved Trust List, so the tick is real rather than self-asserted; the document has not been modified since signing; the signature carries an embedded timestamp, so when it was signed does not rest on anybody’s clock; and it is LTV enabled, meaning the validation material travels inside the file, so it still verifies years from now when the certificate that signed it has long expired.

This is a genuinely different thing from the free tier, not a coat of paint on it. It’s real infrastructure: certificate issuance, key custody, and an off-platform signing step that has to run somewhere with real security guarantees around it. Because of that, it’s a premium capability, and it goes out organisation by organisation as a conversation rather than a self-serve toggle: each org that wants one needs a certificate issued and a trust arrangement put in place under its own identity, which is not something a setting can do for you. The signing path underneath it has come a long way too: the seal is applied within seconds of the last signature rather than on a later sweep, so a signer usually leaves with their final sealed copy on screen, and document size is no longer bounded by what a signer’s browser can hold. If baseline compliance covers you, and for most people signing most documents it does, there’s nothing to do. If you’re one of the people who needs the tick specifically, whether that’s a counterparty’s procurement policy or your own peace of mind, get in touch and we’ll talk you through where it’s up to for your org.

Why the native tier can stay free

Every incumbent charges per envelope or per user, and it’s worth understanding why, because the answer explains our pricing too, on both tiers.

A conventional e-signature service runs real infrastructure on your behalf: servers that store and render your documents, email and SMS pipelines, key management, compliance certifications for the data they hold, and an operations team around all of it. Those are genuine marginal costs, and per-envelope pricing is how they’re recovered. The subscription isn’t rent on the feature, it’s rent on the infrastructure.

Native Sliick Docs e-signature has no such infrastructure, by architecture rather than by discount. Documents render with Salesforce-native PDF generation. The signing portal is your own Experience Cloud site. Verification PINs travel through Salesforce email. The evidence chain is rows in your org, hashed by Apex. This tier makes no outbound network calls, which is simultaneously the data-residency guarantee (your residency is exactly your org’s residency, nothing to add to your vendor register) and the cost structure. There’s no per-envelope cost for us to recover, so there’s no per-envelope price for you to pay.

The trade-off is equally honest: you bring the platform. Signing runs on your Experience Cloud capacity, emails count against your org’s limits, and storage is your org’s storage. For organisations already running Salesforce, that marginal cost is effectively zero, which is the point, and it’s why this tier is free forever regardless of what happens with the premium tick above it.

I felt this one before I got around to writing about it. I tried DocuSign myself, on the free plan, for about a month, and stopped there. I wasn’t sending anywhere near enough agreements to justify what the cheapest paid plan would have cost every month regardless of whether I used it, a flat fee for envelope headroom I didn’t need. So I never became a paying customer at all. That’s the gap native e-signature actually closes for a business like mine: not a cheaper subscription, no subscription. Every agreement I send now goes out through the same native e-signature described above, on our own Salesforce org, at no separate cost.

There’s a second, quieter benefit that doesn’t show up on anyone’s pricing page: whose name is on the email. A DocuSign invite arrives from DocuSign’s own sending infrastructure, whatever branding sits on top of it. Ours don’t. Because a signing invite is just Salesforce email, ours go out as @Sliick.com, not a third party’s domain, and if your org has its own sending domain configured, yours will too.

What the tick actually costs to run

The cryptographic tick, and every assurance tier above it, re-introduces exactly the external infrastructure whose absence makes the native tier free. None of it is free for anyone, including DocuSign, and naming that plainly seems more useful than pretending otherwise. I’m not going to put figures on it here, because the honest number depends on volume, jurisdiction, and which combination of the items below you actually need, and because that’s a conversation, not a price list. But it’s worth being clear about what kind of cost each one is:

• Cryptographic document sealing (the green tick itself). Certificate authority relationships and key custody are a standing cost that exists whether or not anyone signs that day, plus real engineering to embed and verify the signature correctly. This is the one we’ve now built.
• Trusted timestamping. A trusted timestamp authority countersigning when a document was signed, on top of our own hash chain, for a per-use or subscription fee, via an outbound call that has to be designed into the residency story rather than bolted on.
• eIDAS Advanced / Qualified signatures (AES / QES). Certificate-based signing under the signer’s own sole control, which is a different arrangement again from the tick above; QES adds qualified trust-service providers and certified hardware, and is the only tier with automatic handwritten-equivalence across the EU. The trust providers charge everyone for this, DocuSign included.
• Stronger identity proofing (document + biometric verification). Email-OTP is appropriate for ordinary commercial documents; high-stakes signing may warrant verified government ID. Specialist identity-verification vendors charge per check, every check is an outbound call, and the experience has to be designed so assurance doesn’t tank completion rates.
• SMS one-time codes. Routinely requested, deceptively expensive: Salesforce has no native SMS, so every code means a gateway relationship and a per-message fee, forever.
• Witnessing and remote online notarisation. Some excluded categories become signable with a witness, which means real-time video, recording storage, and rules that differ by jurisdiction. The largest design problem on the list.

There’s also a cost that isn’t a fee at all. Every tier here except the tick we’ve built requires an outbound call, which is precisely the property the native tier doesn’t have. Adding one re-introduces a middleware layer to run and monitor, credentials and call limits to manage, retry and failure handling, and a new subprocessor on your vendor register. That operational burden is separate from, and routinely underestimated next to, the per-use price.

None of this is a pricing announcement. It’s the honest map of what real assurance costs to run, on our side and everyone else’s, and why the tick sits behind a conversation instead of a checkbox.

Want the tick?

Native e-signature in Sliick Docs is free, forever, and for most people signing most documents it’s already the right answer, it’s the same category of signature my solicitor used on me. If you’re one of the people who specifically needs the Adobe-trusted green tick, whether that’s a counterparty’s requirement or your own preference, get in touch. Tell us your document types and volumes, and we’ll be straight with you about whether the native tier already covers it, and if it doesn’t, what the tick involves for your org.

Related reading

• Sliick Docs v2.5 release announcement - what shipped most recently.
• Sliick Docs v2.4 - public document verification and a fuller Certificate of Completion.
• Sliick Docs Complete User Guide - the full reference.
• Sliick Docs product page - feature overview and install link.