I Needed to Sign a Lease — So I Built E-Signature Into Salesforce Instead

I needed to sign a 12-month residential lease today. The landlord sent the PDF over email. I have a Salesforce-native delivery platform sitting at cloudnimbusllc.com/portal, an internal document engine that already generates branded PDFs, and a soft preference for not paying $25/month to DocuSign for the privilege of clicking “sign here.” So I built e-signature into Delivery Hub instead. It took an afternoon. Here's the footage and the architecture.

What I Wanted

DocuSign exists. HelloSign exists. Adobe Sign exists. They all solve the problem. They also all have the same tradeoffs:

• Per-signature or per-seat fees that scale with volume regardless of the underlying cost (which is roughly zero).
• External system of record. The signed document lives in their cloud, not next to your project, your client record, or your invoice.
• Brittle integrations. If you want the audit trail in Salesforce, you pay for a connector or you scrape the webhook.
• Onboarding friction for the signer. “Click here to create an account so you can click here to sign this thing.”

What I actually wanted was the simplest possible thing: send someone a URL, they open it, they see the document, they draw a signature with their finger or mouse, they hit submit, and a tamper-evident record of who signed what at which timestamp from which IP lands inside Salesforce next to the work that produced the document. No accounts. No emails about “your envelope is ready.” No subscription.

What I Built

Delivery Hub already has a Document Engine — see the document engine docs — that generates invoices, status reports, client agreements, and contractor agreements from Salesforce data, freezes them into immutable JSON snapshots, and renders them as PDF or as React components inside the portal. I extended it with three new pieces:

1. DocumentAction__c — one row per signer slot per document. Holds the signer's name, email, role label (“Lessee,” “Lessor,” “Approver,” whatever the document needs), a unique signing token, status, and the captured signature data when they sign.
2. Token-based public route. A signed link looks like cloudnimbusllc.com/portal/sign/<64-char-token>. The token is a hex-encoded 256-bit AES key, generated server-side, single-use per signer. No login required — opening the link is the credential.
3. Audit-trail capture. When a signer hits submit, the route captures their IP address, user-agent, electronic consent timestamp, and the signature image bytes (a PNG of what they drew on a canvas). Everything is written into Salesforce fields on the DocumentAction__c row, and a corresponding ActivityLog__c entry rolls forward a SHA-256 hash chain that links every signing event to the previous event in the same document. Tamper any record after the fact and the chain breaks.

That's the entire backend. Three custom objects already existed (DeliveryDocument__c, NetworkEntity__c, ActivityLog__c); the only new one is DocumentAction__c.

What the Signer Sees

Open the link. Scroll. The document renders inline as a real React component — not a PDF in an iframe — so it's readable on a phone, accessible to screen readers, and the signature blocks at the bottom are real DOM elements. Above each signature line is the signer's name. If the other party has already signed, their drawn signature appears above their name with a green panel underneath showing exactly when they signed, from what IP, and when they consented to e-sign.

Below the document is a signature pad. You draw with your finger or mouse. There's an explicit consent checkbox: “I agree to use electronic signatures and that this signature is legally binding.” You hit Sign. The page fires off a POST to the same token-scoped route, the backend validates the token, captures the audit metadata, persists the signature image as a Salesforce ContentVersion, and flips the slot to Completed. When the page reloads, your signature is now baked into the document above your name and the “Document History” footer at the bottom of the lease has gained an entry attesting to who signed when from which IP.

How It's Wired Together

The signing flow has three parts: a Salesforce REST endpoint that owns the data, a Next.js proxy on cloudnimbusllc.com that handles the public traffic, and a React page that renders the document and captures the signature.

The Audit Trail Bit Is the Whole Game

E-signature laws (ESIGN Act in the US, UETA in 49 states, eIDAS in the EU) all hinge on the same idea: you have to be able to prove, after the fact, that a specific person consented to sign a specific document at a specific time. The signature image itself is almost irrelevant — courts care about the metadata around it.

Delivery Hub captures every required field on every sign event:

• Identity binding — the signer's name and email are baked into the slot before the signing link is even generated. The link is single-use and scoped to that one slot.
• Intent — explicit consent checkbox text is recorded with timestamp.
• Attribution — IP address and user-agent string from the request that submitted the signature.
• Tamper evidence — every sign event writes a row to ActivityLog__c whose hash field is SHA-256(previousHash || currentEventBody). Any attempt to alter a prior signing event breaks the chain at every subsequent event.
• Document integrity — the underlying DeliveryDocument__c stores the entire frozen content snapshot as JSON. The signature is bound to that exact snapshot, not to the live data that produced it. Editing the source after signing does not change the signed document.

That's enough to satisfy ESIGN/UETA requirements for most commercial use cases. For higher-stakes documents (deeds, wills, certain financial instruments) you'd want notary integration on top — but those are exactly the documents you wouldn't send through any e-sign platform without specialized review anyway.

Why Salesforce-Native Matters

The signed document and its audit trail live in the same database as the work that produced the document. That's the unlock.

• A signed contractor agreement is automatically related to the contractor's NetworkEntity__c record. Open the contractor, see every signed agreement, every status change, every work item under each one.
• A signed change-order document automatically rolls into the project's timeline, the invoice generator, and the activity feed. There's no integration to maintain because there's no second system.
• A signed approval document fires the same DeliveryDocEvent__e platform event that the rest of Delivery Hub listens to — flow triggers, automation, dashboards, and the portal's real-time activity feed all react instantly.

This is the whole reason Delivery Hub is Salesforce-native instead of being a SaaS sitting next to Salesforce. The data model compounds.

The Real Lease

The triggering use case was a 12-month residential lease I needed to sign and return to the lessor today. It went through the same flow you saw in the video: I generated the document, set up two signer slots (lessee, lessor), got two unique tokens, opened my lessee link, drew my signature, and watched the slot flip to Completed in Salesforce. The lessor will open their link, see my signature already baked into the document with the audit panel underneath, draw theirs, and the document hits Fully Executed status with a Document History footer attesting to both events.

Total cost: zero. Total integrations: zero. Total accounts the lessor has to create: zero. The whole thing is one URL.

What's on the Roadmap

• More document templates. The signing pipeline is template-agnostic; I just need to write more renderers (NDA, SOW, MSA, change order, deed of assignment, vendor onboarding packet).
• SMS delivery for the signing link in addition to email. The link is the credential — meeting the signer where they actually read messages matters.
• Bulk signing for documents that need a single signer to sign multiple documents at once (e.g. an end-of-quarter batch of timesheets).
• Notarization integration for the small set of documents that legally require it.
• Public certificate of completion download — a signed PDF that bundles the document, the audit trail, and the hash chain proof into a single artifact for archival.

Try It

The Document Engine — including the new e-signature flow — is included in every Delivery Hub installation. There's no per-signature fee, no add-on, no subscription tier. If you're already on Delivery Hub, generate a document, add signer slots, and send the link.