Route Completed Salesforce Documents to DocuSign for Signature

The most common question about signature is the wrong question. People ask how to connect their document generation tool to their signature platform. But once completed documents are sitting on a Salesforce record, there is nothing left to connect. DocuSign is already there, reading the record — and Salesforce can tell it to send.

This is the last leg of the loop covered in generating documents from a Salesforce record with Zapier and returning them to the record. That article ends with the completed files attached to the Opportunity, Case, or custom object that started everything. This one closes the loop.

Why no integration is required

By the time the signature step arrives, the documents DocupletionForms produced are not DocupletionForms documents anymore. They are ordinary Salesforce files, attached to a Salesforce record, subject to Salesforce sharing rules. Any tool with permission to read that record can read them.

This is not a workaround. It is what DocuSign’s own support team tells people to do. Asked how to take a document produced by a third-party generation tool and send it for signature alongside other files, DocuSign’s answer is that when the tool attaches the file to the record, both DocuSign for Salesforce and the DocuSign Apps Launcher can use that attached file as the source document for an envelope. The discussion is public on the DocuSign community forum.

Each layer does the job it is built for. Salesforce is the system of record. DocupletionForms is the document layer that turns record data into the correct, complete set of documents on fixed rules. DocuSign collects the signatures. Nothing reaches across a boundary it has no business crossing — and the automation that ties them together is Salesforce’s own.

The one decision that determines whether this works: Files or Attachments

Salesforce stores record documents in two places, and they are not interchangeable. Salesforce Files (ContentVersion) is the modern store. Notes and Attachments is the legacy store. Which one your completed documents land in decides how DocuSign retrieves them — and it decides it before DocuSign is ever involved.

Inside the DocuSign envelope configuration, the corresponding controls are Load Files and Load Attachments. Separate options, matching the two Salesforce stores. Point the envelope at the store your documents are actually in.

This is why the return method you choose in the generation step is a design decision and not a preference. Make it deliberately, upstream, rather than discovering after the fact that the envelope configuration cannot see the file. Salesforce Files, notes, and completed PDFs compares the options on sharing behavior, storage consumption, and retrieval.

Closing the loop: sending the envelope from a Flow

A loop that ends with a person remembering to click a button is not a loop. It is a workflow with a gap in it, and the gap is where documents sit unsent for three days.

DocuSign supports automated sending from Salesforce, and documents it themselves. DocuSign eSignature for Salesforce is built on the Apex Toolkit and ships reusable envelope configurations along with invocable actions for process automation. Their published guides cover sending an envelope from a Salesforce Flow, sending an envelope with the Apex Toolkit, and sending an envelope from an Apex trigger. The DocuSign eSignature for Salesforce overview is the place to start.

The clicks path: a reusable envelope configuration plus DocuSign’s invocable action, called from a record-triggered Flow. No Apex.

The code path: the Apex Toolkit, invoked from a Flow or an Apex trigger, when the envelope needs to be assembled conditionally — different recipients, different routing order, different templates depending on the record.

Either way, the automation lives in Salesforce and calls DocuSign. DocupletionForms is not in this step at all. It finished its work when the documents hit the record.

The gate: what has to be true before an envelope sends

Read this section before you build the Flow. Sending an envelope is irreversible and client-facing. A document generation error can be corrected before anyone sees it. A signature request cannot be unsent. The gate below is not optional hardening — it is the difference between an automation and an incident.

Never trigger the Flow on a generic record update. Consider what a naive version does. Documents return to the record, so the record is updated, so the Flow fires and sends the envelope. The recipient signs. DocuSign Connect writes the signed document back to the record. The record is updated. The Flow fires again. Your client receives the same agreement to sign twice.

Two fields prevent this, and both belong on the record:

• A controlled status field — a picklist, not a checkbox, with explicit values such as Awaiting Documents, Documents Generated, Envelope Sent, Signed. The Flow’s entry criteria is a transition into Documents Generated and nothing else. A picklist rather than a checkbox because a checkbox cannot express where in the sequence a record is, and it is the sequence that governs.
• An integration lock field — set when the Flow begins, cleared when the envelope send returns. Two concurrent updates to the same record cannot both send.

These are the same controls that keep the generation step from firing twice. Upstream, a documents-generated flag stops a record edit from regenerating the packet. Downstream, a status transition stops a record edit from resending the envelope. The pattern is identical because the risk is identical: an idempotent workflow is one where running it twice does the work once.

Consider a human checkpoint before send. For regulated or client-facing paperwork, a status value of Ready to Send that a person moves to Approved costs one click and buys a review of the packet before it becomes binding. Fully automatic send is appropriate where the document set is high-volume, low-variance, and low-consequence. It is a poor default for a retainer agreement, a disclosure packet, or anything with a filing deadline attached to it. Decide which one you are building, on purpose.

Building the envelope

Configuration lives on the DocuSign side, in DocuSign’s own product, and their documentation is the authority. The shape of it:

1. Create an envelope configuration on the object your documents attach to — the Opportunity, Case, Account, or the custom object your workflow is built around.
2. Add documents from the record using Load Files or Load Attachments, matching the store your completed documents landed in. A packet of three documents sends as one envelope with three documents. The recipient signs once, in one sitting, rather than receiving three separate requests.
3. Pull recipients from the record. DocuSign can add recipients dynamically from Salesforce records, users, or contacts rather than requiring a person to type an email address. The signatory is already on the record that generated the documents.
4. Place fields once. Because the documents are produced deterministically from the same PDF templates every time, a signature block sits in the same position on every copy. Saved field placement stays reliable instead of needing a look every send. This is a direct, practical dividend of rule-based generation — a document assembled differently each time could not support saved field coordinates at all.
5. Call it from the gated Flow, and let the status transition — not the record update — be what fires it.
6. Return the signed document to the record. When every recipient has completed their fields, the signed document is saved back to the Salesforce record. Have the Flow that handles that write the status to Signed, closing the sequence.

Prerequisites, plainly. A DocuSign eSignature entitlement and the DocuSign app installed and configured in your Salesforce org — both on the DocuSign side of the line, and both things most Salesforce organizations that collect signatures already have. DocupletionForms requires no DocuSign configuration, because DocupletionForms never talks to DocuSign. It talks to Salesforce.

Why the packet arrives complete

An envelope is only as good as what goes into it. Signature platforms sign what they are handed; they do not decide whether the right documents were handed to them.

That decision belongs upstream, and it is the reason the generation step runs on conditional rules rather than on interpretation. The record’s own fields determine which documents apply — state, contract term, deal size, matter type, entity structure. Those rules are written once, reviewed once, and produce the same packet for every matching record afterward. Nothing is composed on the fly, and nothing is inferred, so nothing arrives at the envelope that a rule did not put there.

When a required field is missing, the workflow stops before generation rather than producing a document with a gap in it. A blank is a data problem to fix on the record, and catching it at the filter turns what would have been a signed defective document into a five-second correction. Why document selection should be rule-based, not AI and what deterministic document automation means cover the principle in full.

This is also what makes automated sending defensible at all. You would not auto-send a packet you could not predict. Determinism upstream is the precondition for automation downstream — the reason it is safe to let a Flow do the sending is that you already know, before it runs, exactly what is in the envelope.

If you use a different signature platform

Everything above holds. The documents are Salesforce files on a Salesforce record. Adobe Acrobat Sign, Dropbox Sign, or any signature tool with a Salesforce app reads records the same way, and the same Files-versus-Attachments decision applies. Check whether your platform exposes an invocable action or Apex method for automated sending; if it does, the gated-Flow pattern above transfers unchanged.

If your signature platform has no Salesforce app, the completed documents can be routed at the moment of generation instead. Bidirectional webhooks report completion and document location to whatever is listening, and Zapier carries the same information onward. Webhooks vs. the Salesforce API covers when each path is appropriate.

The architecture does not care which signature platform you chose. It cares that the documents were correct before anyone signed them.

Frequently asked questions

Does DocupletionForms integrate with DocuSign directly?
No, and it does not need to. Completed documents are returned to the Salesforce record through the DocupletionForms Salesforce API integration. A Salesforce Flow then calls DocuSign’s invocable action, and DocuSign’s Salesforce app loads the documents from that record. Every step of the handoff happens inside Salesforce.

Can the envelope send automatically, without anyone clicking?
Yes. DocuSign publishes guides for sending an envelope from a Salesforce Flow, from the Apex Toolkit, and from an Apex trigger. Gate the Flow on a controlled status transition rather than a generic record update, or the signed document returning to the record will re-fire it.

Should it send automatically?
Not always. Sending an envelope is irreversible and client-facing. For high-volume, low-variance paperwork, automatic send is appropriate. For retainer agreements, disclosure packets, or anything with a filing deadline, a one-click human approval step before send is the safer default.

Can one envelope contain a whole multi-document packet?
Yes. An envelope can hold multiple documents, and the recipient signs across the packet in a single session rather than receiving a separate request per document.

Should completed documents go to Salesforce Files or Notes and Attachments?
Decide before you build. DocuSign’s envelope configuration exposes Load Files and Load Attachments as separate options, matching the two Salesforce stores. Files is the modern store; Notes and Attachments is legacy. The envelope configuration must match wherever the documents land.

What stops the same envelope from sending twice?
A controlled status picklist that the Flow keys on, and an integration lock field set for the duration of the send. The same idempotency discipline that stops the generation step from firing twice.

Can I use a signature platform other than DocuSign?
Yes. The completed documents are ordinary Salesforce files. Any signature platform with a Salesforce app can retrieve them, and platforms without one can be reached through webhooks or Zapier at the moment of generation.

Related reading: the sibling article, generating documents from a Salesforce record with Zapier and returning them to the record, covers everything upstream of signature. The Salesforce, Zapier & DocupletionForms data-options overview maps the full Salesforce series.

DocuSign is a trademark of DocuSign, Inc. DocupletionForms is not affiliated with DocuSign. Configuration steps for DocuSign products are described according to DocuSign’s published documentation and are subject to change; consult DocuSign’s documentation for current guidance.