Installing the Docusign managed package gets you a send button. It does not tell Salesforce that the contract came back, update the stage, file the executed PDF against the record, or capture what the signer typed into the form. That configuration is the integration — and it is where most Salesforce and Docusign implementations stop short.
A Docusign Salesforce integration is a two-way link between a Salesforce record and a Docusign envelope. Data flows out of Salesforce to compose and address the document; envelope and recipient status, the executed document and anything the signer entered flow back to update the record. Docusign provides the managed package, the Apex Toolkit and the Connect notification service that make this possible. The integration work is deciding which objects and fields participate, in which direction, and what Salesforce should do when each status arrives.
Business purpose, plainly: so that the CRM's picture of a deal reflects the agreement rather than trailing it by however long it takes someone to notice and type. Every downstream consequence — forecast accuracy, provisioning triggers, invoicing, renewal tracking — depends on that one fact being current and automatic.
Docusign eSignature for Salesforce covers sending, signing and status. Docusign CLM for Salesforce adds generation from a template library, a structured contract repository and configurable review and approval workflow, with one-click generation from opportunity data. They solve different problems and are licensed separately. The usual mistake is buying CLM to fix a writeback problem, or trying to force eSignature to carry a contract lifecycle it was never meant to hold.
Three patterns account for most of the remediation work we are asked to do. Writeback is configured for envelope completion only, so nothing distinguishes "declined" from "still waiting". Recipients are resolved from a single field rather than from contact roles, so multi-party agreements are addressed by hand. And the send action is a button with no preconditions, so envelopes go out against records that are missing the values the document needs.
Most of an integration engagement is Salesforce work, not Docusign work. The platform capabilities below are Docusign's; the design decisions around them are what we are engaged for.
Install, connect the Salesforce org to the Docusign account, and configure the sending settings, layouts and permission sets so each role sees the send action it should and none of the ones it should not.
The Apex Toolkit is what the managed package itself is built on, and it is how a send experience gets tailored: composing envelopes in code, resolving recipients from related records, and applying document and field logic the declarative setup cannot express.
Docusign supports mapping envelope and recipient status to Salesforce field updates — setting a checkbox when a recipient has viewed, moving a stage on completion. We define that mapping per agreement type, including the negative paths, and confirm the sending user's permissions actually allow the updates.
Where the signer completes fields — a purchase order number, a delivery address, a consent option — those values come back to Salesforce fields rather than being trapped in the PDF, so downstream automation can act on them.
Completion is a trigger, not an ending. We wire the status change into the automation that should follow it — provisioning tasks, finance handoff, renewal date calculation — using record-triggered flow so the logic stays where administrators can maintain it.
Where the requirement is contract lifecycle rather than signature: generating contracts populated from opportunity data, routing them through approval, and holding them in a repository that can be reported on. Covered in depth on the CLM implementation page.
The integration design falls out of this mapping. Decide what the agreement does to the record at each stage, and the field, object and automation decisions mostly answer themselves.
| Stage | Agreement action | What changes in Salesforce |
|---|---|---|
| Proposal | Quote or proposal generated from opportunity and line-item data and sent for acknowledgement. | Document filed to the opportunity; sent timestamp recorded; delivery and view status visible on the record. |
| Negotiation | Non-standard terms requested. Where CLM is in use, redlines and clause fallbacks are handled in the workflow rather than by email. | Approval status and approver identity recorded; non-standard-terms flag raised for reporting. |
| Contracting | Final agreement routed to signers in defined order, with the identity check the document type requires. | Recipient-level status updates as each party acts; declined or voided outcomes set their own field values, not silence. |
| Closed Won | All parties have signed; Docusign issues the Certificate of Completion. | Stage moves on the completion event; executed document and certificate filed; downstream flow fires. |
| Provisioning | Executed terms are the input to fulfilment, invoicing and revenue recognition. | Signer-entered values and contract terms pass to the finance or ERP system from fields, not from a PDF. |
| Renewal | Renewal and notice dates are derived from the executed agreement. | Dates stored as fields on the contract or account record, so they can drive tasks, alerts and reports. |
These are the points where a Docusign Salesforce integration is usually either sound or quietly storing up work. None of them are difficult to get right at design time; all of them are expensive to change once volume is flowing through.
They are also the questions we ask first when reviewing an integration somebody else built.
Sending from the opportunity is the default and is often wrong. Where one deal produces several agreements, or agreements outlive the opportunity, a dedicated agreement object gives you a place to put status, dates and terms that reporting can reach.
Writeback runs in the sending user's context and requires update permission on the target objects and fields. A mapping that works for an administrator in testing and silently fails for a sales user in production is the classic version of this defect.
Apex Toolkit code written against a single record will fail the first time it meets a bulk update or a data load. Envelope composition belongs outside synchronous transaction limits where volume warrants, with queries and DML bulkified from the start.
A Salesforce sandbox must point at a Docusign demo account, not production, or testing sends real agreements to real people. Refreshing a sandbox resets that pairing, which is why re-linking belongs in the refresh runbook rather than in somebody's memory.
Replacing an incumbent e-signature tool leaves buttons, fields, flows and triggers referencing it. Retiring them deliberately is part of the work; leaving them is how the next administrator inherits an org where two signature paths appear to exist.
Most orgs we look at have the package installed and the send button working. The gap is everything after the signature. A review of your org and your Docusign account will tell you which of the signals opposite apply and what it would take to close them.
