Signature providers & DocuSign#

Welisa DocGen signs documents with its built-in engine by default. For clients who already own DocuSign, Welisa DocGen can route signature requests to DocuSign instead — chosen by a configuration record, not by code: no Flow edits, no Apex changes. This page explains the two modes, the shared Send for Signature action, the envelope tracking that works for either provider, and the DocuSign specifics.

Built-in signing versus an external provider#

Two consequences you will notice in the quick action: with built-in signing the action skips generation entirely and lets the signing engine merge (pre-generating would leave two documents on the record); and the "use a file on this record" option is only offered when the configured provider can serve it.

The Send for Signature action#

The Send for Signature quick action (place it on the object's record page; users need Welisa Signing) is the one place a person sends from, whatever the provider: pick a template (or an existing file, for an external provider), one signer row per role found in the template with the role locked, optional advanced options (anchor text for DocuSign, e-mail subject and message), preview, send. Its Earlier requests section shows every send for the record with Resend and Cancel request.

From automation use the Welisa: Send for Signature Flow action — place it after Generate Document for an external provider and pass the generated Content Version Id; for built-in signing pass the template. Signature requests created this way go through an envelope (below).

Envelopes — one record per send, whatever the provider#

Every send through the action creates a Welisa Envelope record — the reason the seam exists: one place to see what was sent where, with which provider, and what happened.

The Welisa Envelopes tab lists them (All Envelopes, Needs Attention). Cancel and resend always run against the provider that sent the envelope, never against whatever is configured now — so switching a client from built-in to DocuSign can never void the wrong envelope or leave a still-signable request live.

Configuring the provider#

A Welisa Signature Setting custom metadata record decides who signs:

Resolution: per-template override → org default → built-in. Built-in signing needs no configuration at all — absent configuration means "use the built-in default".

DocuSign#

The DocuSign adapter is a small separate package that Welisa installs and configures for clients who own DocuSign. It builds on the DocuSign eSignature for Salesforce managed package and its Apex toolkit: the client owns the DocuSign account, seats, envelope billing, key custody and go-live. Welisa does not resell DocuSign.

Prerequisites in the client org#

1. The DocuSign eSignature for Salesforce package installed and the account connected through its Docusign Setup tab.
2. The sending user must be a sender on that DocuSign account. The toolkit requires it, so system and batch contexts cannot send — use a designated integration user with a DocuSign seat.
3. The adapter installed by Welisa, and the DocuSign Sender permission set assigned.
4. A Welisa Signature Setting record: Provider Class = DocuSignProvider, Is Active = true, Template API Name blank (org default) or a template's API name (route only that template to DocuSign).

Anchor text — read this before debugging a missing signature box#

DocuSign places fields by anchor text: a token it searches for in the PDF's text layer. Built-in signing uses {@Signature_…} tags; the two mechanisms are unrelated, and a template written for one does not work with the other.

1. Put a unique token in the template, in white text so it is in the text layer but invisible to the reader:

   Copy

   <p><span style="color: #ffffff;">/sig1/</span></p>

   Use color: #ffffff, never display: none — hidden text is never rendered at all, so there is nothing to find.

2. Give the same token to the signer. In the action, open Show advanced options and type /sig1/ into Anchor text for that signer.

Anchor facts learned from live envelopes: matching is substring-based, so uniqueness of the token is what prevents unwanted matches — never use a common word; the anchor text stays visible in the finished PDF unless it is white-on-white; never position fields by x/y coordinates (generated documents reflow, anchors move with the content); no anchor and no role means no field, which DocuSign treats as free-form signing.

Operations#

Limits#

• Cancel and resend are callouts, so the adapter calls DocuSign before updating the envelope record.
• Callout bodies cap at 6 MB synchronous / 12 MB asynchronous, and base64 inflates a PDF by about a third, so documents above roughly 8 MB cannot be sent.
• DocuSign has no idempotency key on envelope creation: a lost response plus a blind retry would bill the client twice. The envelope record is written before the send so a retry is detectable.
• Open items at the time of writing: the per-send e-mail subject and message are accepted but not yet forwarded to DocuSign, and envelope status is not yet written back from DocuSign to the Welisa Envelope (it stays Sent until cancelled). Ask Welisa for the current state.

Which should a client use?#

Built-in signing covers most contracts, quotes, approvals and consent forms, at no cost and with a complete audit trail and certificate. DocuSign makes sense when the client already standardises on it, needs an existing file on the record signed, or needs an assurance level above SES. Because the choice is a configuration record, a client can start built-in and switch later — or route only specific templates to DocuSign.