Salesforce eSignature: How to Send Generated Documents for Signing Without Leaving Your CRM 

360 InstantDocs is one of the best Salesforce document generation apps for teams that need a document signed the moment it’s ready, not an hour later. Here’s the process most Salesforce teams are still running. Generate a document from a record. Download it. Open DocuSign in another tab, upload the same file, add recipients, and hit send. Wait. When the signed copy comes back, someone has to remember to attach it to the record manually, if they remember at all. That’s four separate systems doing one job, and the audit trail breaks the second the file leaves Salesforce. Salesforce esignature done right doesn’t require any of that. The document generates, gets sent for signature, and comes back signed, all from the same record. 

One dropped signature request is one too many. See how the workflow closes that gap.

Book a demo

Does Salesforce Have Built-In eSignature? 

No, it doesn’t. This trips people up because Salesforce feels like it should have everything built in, and it doesn’t have native eSignature. What it has is an ecosystem. Teams install an AppExchange app to handle signing, and the three most common are DocuSign, Dropbox Sign, and Conga Sign. 

Here’s the distinction that actually matters, though. Having an eSign app installed is not the same as having a connected workflow. Plenty of orgs run DocuSign and Salesforce side by side, completely disconnected, with someone manually bridging the two every time a document needs signing. A real eSignature for Salesforce setup means the document generates from record data, launches straight into the signing app without a download step, and the signed result lands back on the record automatically. That gap between “installed” and “connected” is where most teams are stuck. 

The Three Salesforce eSignature Apps Compared 

DocuSign is the name most people know, and for good reason. It’s the deepest Salesforce integration of the three, with the widest recipient recognition (clients rarely blink at a DocuSign email), and it scales well for enterprise volume. Pricing sits at the higher end, which makes sense given the market position. 

Dropbox Sign (formerly HelloSign) appears to attract organizations which would prefer an easier user interface and less expensive pricing options. This option includes everything that is needed from the sign-up process: templates, sequencing of the signature, auditing history without the extra functionality overload which comes with DocuSign. 

Conga Sign appears to be useful for those teams that have other products from Conga in their current toolkit. Such product will fit better because there won’t be any need to learn a completely new technology as a part of the system you use. 

None of these options can be considered objectively better than others. Each option should be chosen according to the budget of the organization and its existing tool stack. Recipient’s expectations concerning the way he or she will receive a document are important as well. 360 InstantDocs supports all three points, thus keeping the workflow exactly the same regardless of the application that is chosen. 

How to Send a Salesforce Document for eSignature Using 360 InstantDocs 

The workflow stays the same regardless of which record type you’re working from. Here’s how it runs using DocuSign, since it’s the most common setup. 

Step 1: Generate the document from the record. Open the Opportunity, Contract, or custom object record and click the document generation button. 360 InstantDocs merges live Salesforce data into the template and produces the finished WORD or PDF. 

Step 2: The file saves automatically. Before anything gets sent anywhere, the generated document attaches to the source record under Salesforce Files. This step matters more than it looks. It means there’s always a system-of-record copy, independent of whatever happens in the signing app next. 

Step 3: Launch the eSign app from the same record. No downloading, no switching tabs to hunt for the file. From the record, launch DocuSign directly. 

Step 4: Select the generated file. The document you just created is already available to select inside the signing flow, since it’s already sitting on the record. 

Step 5: Add recipients. Pull email addresses straight from Contact or Lead fields on the record instead of typing them in manually. Fewer typos, fewer bounced signature requests. 

Step 6: Place signature fields. Standard DocuSign tagging, drag the signature and date fields onto the document. 

Step 7: Send. The recipient gets the signing request, and Salesforce keeps a live link to the transaction. 

Dropbox Sign and Conga Sign follow this exact same sequence. Generate, save, launch, select, add recipients, tag, send. The interface changes slightly. The workflow doesn’t. 

How the Signed Document Returns to Salesforce 

This is the part most teams don’t realize happens automatically, and it’s arguably the biggest reason to connect generation and signing in the first place. 

Once every recipient signs, the completed PDF routes back to the originating Salesforce record, filed under Notes and Attachments or Files, without anyone downloading it from DocuSign and re-uploading it. The record now holds both versions: the original generated document and the fully executed one, sitting side by side. 

Each signed document also carries a Document ID from the eSign platform, so if a signature ever gets questioned, there’s a traceable record tying the executed file back to the exact transaction and timestamp. That’s the audit trail most manual processes quietly lose. Nobody plans to lose it. It just falls through the gap between systems. 

Sequential signing, recipient roles, write-back settings, happy to walk you through it.

Talk to our expert

Setting Up Sequential Signing in Salesforce 

Some documents need signatures in a specific order. A manager approves before a client signs. A vendor countersigns only after the client commits first. Sending everything at once defeats that logic entirely. 

Both DocuSign and Dropbox Sign support sequential (or “routing order”) signing, and it plugs into the same 360 InstantDocs workflow described above. When adding recipients in Step 5, assign each signer a routing number instead of sending to everyone simultaneously. Signer 1 receives the request first. Signer 2 doesn’t get notified until Signer 1 completes their part. Conga Sign supports the same concept through its own signer sequencing settings. 

Worth getting right early. Reconfiguring signer order after a document has already gone out usually means voiding the envelope and starting over, which is its own kind of frustrating conversation to have with a client. 

Common eSignature Workflow Mistakes in Salesforce 

A handful of mistakes show up over and over. 

Launching the eSign app before the document has actually saved to the record. The signing app can’t find a file that isn’t there yet, so give generation a moment to complete. 

Sending the wrong file version. If a template gets edited or a document regenerates, make sure the correct version is the one selected in the signing flow, not an older draft still sitting in Files. 

Skipping recipient roles. Without a defined signer versus CC role, some platforms default to unpredictable behavior, and the wrong person ends up with signing rights. 

And the quiet one: not enabling the signed document write-back setting. Without it, the executed file never makes it back to Salesforce automatically, which puts you right back to manually uploading, the exact step this whole workflow exists to remove.