E-signatures#

Collect legally valid electronic signatures directly from Welisa DocGen — no third-party tool required. Built-in signing is a Simple Electronic Signature (SES): guided field-to-field signing on the real PDF, drawn or typed, e-mail PIN verification, document packets, parallel or sequential signers, reminders, a decline flow, and a Certificate of Completion with a SHA-256 document hash and a public verification page. Clients who own DocuSign can route requests there instead — see Signature providers.

Before the first request, complete the one-time E-signature setup.

Sending a signature request#

Three ways to send, all landing on the same signing experience:

• Send for Signature (quick action on the record page) — pick a template (or, with an external provider, an existing file on the record), choose signers, preview the merged document, send. The template's signature tags define the roles, so one signer row is pre-built per role with the role locked.
• Welisa Signature Sender (record-page component) — pick one or more templates (a packet), add signers from the record's Contacts or by hand (name, e-mail, role), set the order, choose the signing order, send. Its Previous Signature Requests list offers View, Resend, Revoke and Sign In Person.
• From a Flow — Welisa: Create Signature Request or Welisa: Send for Signature; see Flow automation.

Each signer receives a branded invitation e-mail with a secure link. Signers verify their e-mail with a 6-digit PIN (unless verification is off), then walk through every placement; the document updates live and signers can leave and resume. After the last signer, the signed PDF with its certificate page is attached to the record and everyone is notified.

Signature tags#

{@Signature_Role:Order:Type} — role (any string, underscores become spaces), order (sequence per role), type Full | Initials | Date | DatePick, optional :inline. {@Signature_Buyer} alone means :1:Full. Plus the {#Signatures} block for a variable number of signers and {?key} for signer form fields. Full syntax in the merge tag reference.

Packets#

Send multiple templates in one session: the signer sees all documents and signs them all before completion. One e-mail, one signing session, one combined signed PDF with a single certificate at the very end. For contract bundles (MSA + SOW + NDA) and onboarding packets.

Signing order#

• Parallel — everyone is invited at once; first to sign is first done.
• Sequential — signers are e-mailed in order; the next is invited automatically when the previous completes. For hierarchical approvals (employee → manager → director).
• Single — an explicit one-signer document; delivers like Parallel.

PIN verification#

By default every signer verifies a one-time e-mail PIN before seeing the document, which protects against leaked links: click the link → request a PIN → it is e-mailed from the configured sender → enter it → the page unlocks. PINs are stored as SHA-256 hashes, expire after 10 minutes and allow 3 attempts.

Verification can be turned off (or forced on) at three levels, the most specific winning: per send (the Signer Verification and Email Pre-fill pickers in the sender, or the Flow inputs), per template (Signer Verification and Pre-fill Signer Email on the template), and the org default in Signature Settings. The setting is stamped on the request at send time, so later changes never affect in-flight requests. The audit record's Verification Method records Email PIN, None or In-Person either way. Pre-fill skips the "type your e-mail" step and sends the code straight to the known address — a convenience, not a reduction in security.

In-person signing#

Users holding Welisa Admin see Sign In Person on a signer row, including in the Previous Requests list for requests sent earlier. A confirmation dialog asks them to attest that they verified the signer's identity in person; the signing page opens in a new tab without a PIN; an audit record captures who bypassed, when, and the attestation.

The signing experience#

Guided and mobile-friendly: PIN verification → signing → review → submit.

Two signer-facing pages exist and coexist; which one a signer lands on depends on the action that created the request:

• Typed-name page (DocGenSignature) — the full document renders inline; a sticky bar shows progress ("2 of 5"); an arrow points at the current placement; tap a placement to type a name, initials or pick a date; a consent checkbox precedes submission. Used by Create Signature Request.
• PDF-viewer page (DocGenSignaturePdf) — the real generated PDF renders in the browser. Each of the signer's spots gets a positioned chip (SIGN HERE, INITIAL HERE, DATE) with a "field N of M" counter and auto-scroll; at each spot the signer draws (mouse or finger) or types; Save moves on after the signer has read, Save & Next opens the next field immediately; an auto Date field stamps today silently, a DatePick opens a native picker. Submission is gated until every required field is done, then a consent-only confirmation. Multi-signer: each signer sees only their own spots and the document chains signer to signer. On a template-snapshot send this page also supports the {#Signatures} block and, on completion, re-renders the document from the send-time data snapshot (immune to later record edits), appends the certificate and attaches the signed PDF.

Stamp card versus inline#

When a signer finishes, each field is composited onto the PDF in one of two styles:

• Stamp card (default) — the drawn or typed ink on an opaque white backdrop with a brand-blue border, an accent bar and a caption Signed by name · date. The renderer is whitespace-aware: it grows the card into whichever side has room, and if neither side has room it degrades to the inline mark automatically so it never covers your text.
• Inline mark (:inline, or the automatic fallback) — just the ink, sized to the line height, no card or caption; sits right after a label (Member signature: {@Signature_Member:1:Full:inline}). Date fields are always inline text.

Either way the full audit trail is recorded on the Certificate of Completion — the caption is presentation only.

Link expiration, reminders, resend and revoke#

• Link expiration — signing links expire after the org-wide default (Signature Settings, default 2 days). Individual sends and the Flow action can override per request (1–365 days). The window is stamped at send time; resending opens a fresh one.
• Reminders — enable in Signature Settings with a comma-separated schedule of hour offsets after send (24, 72, 168). An hourly job sends each due reminder once; reminders stop when the window expires; missed offsets collapse into one catch-up.
• Resend — rotates every unsigned signer's link (old links stop working, PIN resets) and re-e-mails them. Revoke permanently invalidates all unsigned links. Both are unavailable once a request is Signed or Cancelled.
• Completed-document delivery — when the last signer completes, every signer's confirmation and the sender's all-signed notification include the signed PDF as an attachment (over 20 MB: notification without attachment; the PDF is always saved to the record).

Audit trail and the Certificate of Completion#

Every signature action creates an immutable Signature Audit record: IP address (captured server-side), user agent, timestamp, consent hash, PIN verification timestamp, verification method, and the action (viewed, signed, declined, PIN bypassed). Field history tracking on the audit fields makes tampering evident.

The Certificate of Completion appended to the signed PDF lists each signer's name, role, e-mail, signed timestamp, e-mail-verified status, IP address and consent, an ESIGN/UETA attestation, and a link to the verify page, where anyone can upload a received PDF to check its SHA-256 hash against the audit record — the file never leaves the browser. (The hash is not printed inside the PDF, because a page inside a file cannot contain that file's own final hash.)

What does not create an audit record: a signature image merged with {%Field}, a signature captured in your own UI and passed to the legacy helper actions against a current request, or a document produced by Generate Document rather than a completed request. A legally defensible signature goes through the signer's link — which can happen in-session inside your own portal (Flow automation).

Signed PDF#

Once all signers complete: every mark is composited as a stamp card (or inline mark) where the tags sit; the Certificate of Completion is appended; the PDF is saved to the source record, named by the template's Document Title Format (falling back to " - Signed"); the request creator is e-mailed a link. In rare fallbacks (a signer's browser could not load the PDF) the server stamps "Electronically signed by X on DATE" text instead — functionally signed, without the card visual.

Decline flow#

Any signer can decline with an optional reason: the request is marked Declined, pending signers are not e-mailed, and the creator receives a decline notification with the reason.

Hiding the Decline button. For binding documents, turn the signer's Decline button off: org-wide in Signature Settings (Hide Decline Button), or per template. Both are off by default. The switch is checked each time a signer opens their link, so it applies to requests already out, and the button is genuinely disabled, not merely hidden.

Signer form fields#

Ask each signer for information before they sign (a PO number, a quantity, an acknowledgement) and have the answers flow into the document ({?key}), the certificate, and — for single-signer requests — back onto the related record. Configuration and limits: Flow automation → Signer form fields.

E-mail branding#

Every e-mail Welisa DocGen sends is an editable, brandable template. Branding is resolved in this order for subject, body, colour, logo and footer:

1. a per-(e-mail type, brand) override saved on the Email Templates tab;
2. the template's Sending Brand;
3. the org-wide Signature Settings value;
4. the built-in default.

The sender address is simply the Sending Brand's Send emails from, then the org-wide one. Reply-to is always the request creator.

Email templates#

Command Hub → Email Templates. Pick the e-mail to edit:

For each: edit the subject and body, preview live with sample data, send a test e-mail, Reset to Default. A Brand dropdown above the layout mode lets you save a wording override for one brand without touching the shared copy.

Two layout modes per template:

• Branded layout (default) — edit just the body; the branded header (logo + colour) and footer are wrapped around it. Override brand colour, logo and footer per template. Logo: a URL of any length, or link a Shared Asset (resolved to its latest image at send time; replacing the asset updates every e-mail), with Logo height in pixels (default 48, up to 200 — upload a transparent PNG at 2× for crisp display). Asset links need Content Deliveries enabled.
• Full custom HTML — paste your entire HTML e-mail (your own table layout, inline styles, <img src="https://…">). It is sent exactly as authored with only tokens and widgets resolved. Images must be absolute, publicly reachable URLs — your website, or Shared Assets via {%asset:key}.

Merge tokens (HTML-escaped at send time): {SignerName}, {SenderName}, {CompanyName}, {DocumentTitle}, {RoleName}, {ExpirationHours}, {RequestId}, {LogoUrl}, {BrandColor}, {%asset:key}, {Message}. Widget tokens render branded blocks: {ActionButton} (the Review & Sign Document button), {DocumentInfo}, {SecurityNote}, {VerificationCode}. A token not supplied for that e-mail type renders empty: {Pin} and {ExpirationMinutes} exist only on the verification e-mail; {SignatureUrl}, {ExpirationHours} and {RoleName} only on e-mails that carry a signing link.

Changing a widget's wording or colour. Widgets render fixed English text with inline styles, so wrapping them in CSS does not restyle them. To change wording, build the block yourself from the underlying tokens — {SignatureUrl} instead of {ActionButton}, {DocumentTitle} + {RoleName} instead of {DocumentInfo}, {SignatureUrl} + {ExpirationHours} instead of {SecurityNote}, {Pin} + {ExpirationMinutes} instead of {VerificationCode} — in Full custom HTML mode:

<table role="presentation" cellpadding="0" cellspacing="0" style="margin: 0 auto 24px auto">
  <tr><td align="center" style="border-radius: 6px; background-color: #384494">
    <a href="{SignatureUrl}" target="_blank"
       style="display:inline-block;padding:14px 32px;color:#ffffff;font-size:16px;font-weight:bold;text-decoration:none;border-radius:6px;">Approve your agreement</a>
  </td></tr>
</table>

Send-time customisation. A single-template send (sender component or Flow) can carry a Custom Email Subject and Custom Email Message that override the saved template for that send; the branded layout and button are kept. Each template also has a Default Email Message that becomes {Message} for its requests — a quote template can say "Please find our proposal attached…" while an NDA template carries different copy. Resolution: send-time message → template default → the e-mail template's generic text.

Brands#

A Brand is a reusable sender identity you can point any template at — how one org runs two entities without their e-mails ever crossing. Command Hub → Brands → + Add Brand:

Set a template's Sending Brand and the request, PIN, signer-completed, all-signed, declined and completion e-mails for that template use the brand — address, logo, colour, company name, footer — unless a more specific per-(e-mail type, brand) override exists. The scheduled reminder e-mail is not yet brand-aware; it uses the org-wide identity. The public signing page and the certificate stay on the org-wide branding.

Setting up a second sending identity: create and verify an Org-Wide Email Address for the entity (Allow All Profiles, DKIM on its domain) → add the brand → point the templates at it → optionally tweak wording per e-mail for that brand → send a test request and check the From address, logo and colour.