Signature status lives outside the CRM
Reps open a separate Docusign inbox to find out whether a contract signed, then update the opportunity stage by hand. Deals sit in "Contract Sent" for days because no one owns the follow-up.
Salesforce · Agreement & Signature Automation
Docusign signs the agreement. Salesforce should own everything around it.
Docusign eSignature for Salesforce puts agreement generation, sending, routing and signature capture on the Salesforce record itself. Twopir Consulting is the implementation partner that configures it around your objects, approval stages and Flows — and builds the writeback so a completed signature actually moves the deal. Implementation, configuration, custom development and legacy-package migration.
12+
500+
40+
250+
Part of the Salesforce delivery work Twopir Consulting has done for 500+ clients — as a Salesforce Partner implementing the agreement and signature layer inside the CRM.
Built For
- Real Estate Brokerages
- Wealth Management Firms
- Legal Operations Teams
- Sales Operations & Deal Desks
- Compliance & Risk Teams
- Financial Services Cloud Users
- Contract Managers
- Professional Services Firms
Signing is the easy part. Everything around it is where deals stall.
Almost nobody has trouble sending a document for signature. The cost sits in the manual work on either side of it — the re-keying before, and the chasing after. That work is configuration, and it is what most implementations skip.
Templates drift away from Salesforce data
Merge fields get typed by hand or copied off the wrong record, so the wrong price, signer or legal entity reaches a document that is about to become binding. Every manual edit is a compliance exposure.
Multi-party routing breaks down
A closing or an onboarding packet needs signers, approvers and CC parties reached in a specific order. Without routing logic configured against real roles, the agreement waits on whoever happens to open it first.
Nothing fires after the signature lands
A completed envelope should close the opportunity, file the document and hand the next team its task. Instead someone has to notice it, open it, read it, and start all of that by hand.
No audit trail tied to the record
Compliance and legal need to show who signed what, when, and against which document version — attached to the Salesforce record, not sitting in a Docusign account that one administrator can reach.
It was configured once and never revisited
The buttons went live years ago, then processes changed around them. Broken merge mappings, dead Flow triggers and templates nobody owns are one of the most common reasons teams call us about Docusign.
Vendor Deadline
The legacy Docusign for Salesforce package reaches end of service on 16 October 2026
Docusign has de-listed the legacy eSignature for Salesforce package from the Salesforce AppExchange and set 16 October 2026 as its end-of-service date, after which the legacy eSignature for Salesforce and eSignature for Salesforce CPQ applications stop functioning and support ends. Docusign publishes the dates and the migration path in its migration article.
If your org is still on the legacy package, the work is to install the current Docusign eSignature for Salesforce application and move buttons, templates, users and records across — Docusign provides a migration tool for that. The part the tool does not do is re-point the automation: Flow triggers, Apex, reports and any custom fields built against the legacy objects. That re-pointing is the actual project, and it is the engagement we are most often called in for right now.
What It Actually Is
Docusign is the agreement layer. We build the Salesforce logic around it.
Docusign eSignature for Salesforce is a managed AppExchange application from Docusign that lets a Salesforce user generate, send, track and capture legally binding electronic signatures without leaving a record. It ships as part of the Docusign Apps Launcher package, which also carries Docusign Gen for Salesforce for document generation, Docusign CLM for contract lifecycle management, and the eSignature Apex Toolkit for developers. Docusign documents the full package and its developer surface in its Salesforce integration documentation.
Installing it is a short job. What takes the time is deciding what it should do: which objects launch an envelope, which fields merge into which template, in what order signers and approvers are reached, what a completed signature is allowed to change, and who is permitted to send at all. Docusign supplies the capability; none of those answers ship with it.
That is the boundary this page is about. Twopir Consulting implements, configures, extends and migrates the application; Docusign provides and supports the product itself. What the client ends up with is an agreement process that starts and finishes on the Salesforce record — and stops depending on somebody remembering to check an inbox.
Four different jobs, and they are not the same engagement
"We work with Docusign" tells a buyer nothing. Here is what each engagement actually contains, what it costs you in involvement, and where configuration ends and custom development begins — the line most proposals leave undefined until it is expensive.
| Engagement | What it covers | Right for you when | Typical search |
|---|---|---|---|
| Implement | Install the current Docusign eSignature for Salesforce package, connect the Docusign and Salesforce accounts, set up the integration user, provision users and permission sets, and stand up a first working send from one object. | You have licences and no working integration yet, and you want a clean, governed starting point rather than an admin experiment. | docusign salesforce implementation partner |
| Configure | Templates mapped to real Salesforce fields, multi-document envelopes, signer, approver and CC routing in the order your process requires, Flow-triggered sends at defined stages, status writeback, and role-scoped send permissions. | The package is installed but people still assemble documents by hand, or routing and status are managed outside the CRM. | docusign salesforce template & routing configuration |
| Build on | Apex and Lightning Web Components against the Docusign eSignature Apex Toolkit, Docusign Connect listeners driving custom post-signature logic, custom objects and Experience Cloud signing journeys, and integrations onward into finance or document systems. | Configuration has genuinely run out — the behaviour you need cannot be expressed in templates, rules or Flow. | custom docusign development salesforce |
| Migrate | Move off the legacy eSignature for Salesforce package before its 16 October 2026 end of service: install the current application, run Docusign's migration tool for buttons, templates, users and records, then re-point Flows, Apex, reports and custom fields and test every send path. | Your org is still on the legacy package, or on eSignature for Salesforce CPQ, and the deadline is now inside your release calendar. | legacy docusign for salesforce migration |
| The boundary | If the outcome can be reached with a template, a merge mapping, a routing rule, a permission set or a Flow, it is configuration — no code, upgrade-safe, and your admins can maintain it. Once it needs Apex, an LWC, or a Connect listener running your own logic, it is custom development, and it carries tests, deployment and a maintenance owner. | Always. We state which side of this line a requirement falls on before the work is quoted, not after. | docusign salesforce configuration vs customization |
The configuration work that turns a send button into a process
A "Send with Docusign" button is a few minutes of setup. Everything below is the project — and it is what decides whether the agreement process actually runs itself a year from now.
Templates & Merge Mapping
Every value on the document comes off the record it belongs to, so nobody retypes a price, a legal entity or a signer name onto something about to become binding.
- Field-level merge mapping to standard and custom objects
- Multi-document envelopes for bundled packets
- Conditional content driven by record values
- Document generation via Docusign Gen where it fits
- Template ownership and change process documented
Routing & Approval Order
Signers, internal approvers and CC parties reached in the sequence your process actually requires — so an agreement cannot skip a reviewer or land on the wrong desk first.
- Role-based recipient routing and signing order
- Internal approval steps ahead of the counterparty
- Conditional recipients based on deal or matter type
- Reminder and expiry policy set per agreement type
- Multi-entity and multi-party closing packets
Flow-Triggered Sending
The envelope leaves when the record says it should, not when someone remembers. Stage changes, approvals and record creation all become legitimate triggers.
- Salesforce Flow launching envelopes at defined stages
- Entry criteria that stop premature or duplicate sends
- Apex Toolkit calls where Flow cannot express the logic
- Error handling and retry paths that surface to a human
- Sandbox-first build with a tested deployment path
Connect Listeners & Writeback
Docusign Connect events land back in Salesforce and drive what happens next, so a completed signature moves the record instead of generating an email somebody has to act on.
- Envelope status written to the record as it changes
- Stage progression on completion, not on a manual update
- Task creation and owner notification downstream
- Signed document and completion certificate filed automatically
- Declined and voided paths handled explicitly
Governance & Audit Position
Who may send, from which records, and what the firm can produce when someone asks for proof — decided during the build rather than after legal asks the question.
- Send rights scoped by profile and permission set
- Completion certificate and history attached to the record
- Document version and template change history
- Reporting on cycle time, stalls and declines
- Configuration documented so it survives staff turnover
Rescue, Migration & Support
Most of what we see is not greenfield. Broken merge mappings, dead Flow triggers, an unowned template library, or a legacy package still running past its end-of-service date.
- Audit of an existing Docusign and Salesforce configuration
- Legacy package migration and automation re-pointing
- Repair of merge mapping and trigger failures
- Post-signature automation retrofitted where it was never built
- Ongoing support through Twopir Salesforce support
What moves between Docusign and Salesforce, and in which direction
The Docusign Apps Launcher package authenticates against Salesforce and exchanges data directly, so there is no middleware layer to buy or run. What matters is deciding what crosses the boundary, and which system is allowed to be right.
Record Data Into the Document
Names, amounts, dates, entities and signer contacts merge from the opportunity, quote, contract or account into the template at send time. Sales and legal stop reconciling two versions of the same figure.
Recipients & Routing Order
Contact roles and record ownership determine who signs, who approves and who is copied, and in what sequence. The routing follows the record's own relationships rather than a hand-picked recipient list.
Envelope Status Writeback
Sent, delivered, viewed, completed, declined and voided land on the record as they happen. Reps, coordinators and managers read signature state in the CRM instead of logging into Docusign to check.
Signed Document & Certificate
The executed document and its completion certificate attach to the record automatically, so compliance and legal can evidence who signed what and when without assembling anything by hand.
Events Driving Salesforce Logic
Docusign Connect notifies Salesforce on envelope events, and Flow or Apex acts on them — advancing a stage, opening the next task, or notifying the team that owns what happens after execution.
Where the Agreement Goes Next
Executed agreements rarely stop at the CRM. We connect the same record onward to document management, billing and finance — the pattern behind our Salesforce and iManage integration work.
Four phases, and the first one is not configuration
Most engagements run four to eight weeks end to end. What moves that range is the number of document types and routing scenarios in scope — not the size of the org, and not the number of licences.
Process & Template Audit
We map every document type you send today: where its data comes from, who signs, in what order, and what has to happen afterwards. This becomes the build specification — not a generic template library.
Template & Routing Configuration
Merge-mapped templates, bundled envelopes for multi-document agreements, and routing logic for signer, approver and CC roles — matched to how your agreements actually move between people.
Flow & Connect Automation
Salesforce Flow launches envelopes at the right stage, and Docusign Connect listeners close the loop — updating the record, filing the document and notifying the next owner the moment a signature lands.
Governance, Training & Handoff
Send permissions scoped by role, the configuration documented, and your admins trained to add the next document type themselves — without re-engaging us to do it.
Where this pattern has already been built
Connecting a document application to Salesforce, writing results back to the record and letting those results drive automation is the same architecture whichever application sits in the middle. Two published engagements, then the four places Docusign earns its keep.
Salesforce & iManage — Law Firm
Document and email management wired into Salesforce, with automation creating the client, the matter and its workspace, and files reachable from the record.
Read the Integration StoryInvoca & Salesforce — Legal Services
A third-party system's events landing in Salesforce as records automatically, with campaign source carried through — the same event-to-record pattern Docusign Connect uses.
Read the Case StudyWhere Docusign Earns Its Keep
Brokerages closing volume leases
Lease, disclosures and addenda bundled into one envelope launched from the opportunity, with Connect events moving the deal stage the moment the last party signs — instead of email attachments and a chase list.
Onboarding under KYC pressure
Financial Services Cloud users send the account agreement, KYC forms and disclosures as a single packet, and completion triggers the next onboarding task automatically rather than a manual handoff.
Multi-party agreements in sequence
Signer, approver and CC roles routed in a defined order so an agreement cannot reach the wrong party out of turn, with every version logged against the matter record.
Closing on the contract stage
The envelope sends when the deal reaches "Contract Sent", and the opportunity closes only once Docusign confirms full execution — removing the gap between signed and recorded as signed.
We implement the product. We are accountable for the process.
Docusign supports its own product, and supports it well. What no vendor can supply is the decision about what your agreement process should do — and that is the part that decides whether any of it holds up.
We map the agreement process before configuring anything
Templates built without understanding how documents actually move just relocate the manual work into Docusign rather than removing it. Phase 01 exists for that reason.
We build the automation, not just the send button
The Flow logic, the Connect listeners and the stage updates around the button are the actual engagement. A page that stops at "we install the package" is describing an afternoon.
We name the configuration and custom-development line up front
Every requirement gets placed on one side of that boundary before it is quoted. It is the most common source of scope disputes on app implementations, and it is avoidable.
We have done this on standard objects and inside Financial Services Cloud
Wealth management onboarding, real estate leasing and standard Sales Cloud contracts route differently from each other. We have configured all three, and they are not interchangeable.
We hand over a system your admins can extend
A new document type next quarter should not mean calling us. The template architecture, the routing model and the automation are documented so your own team adds the next one.
What teams ask before the first call
No. Docusign eSignature for Salesforce is a managed AppExchange package that authenticates directly against your Salesforce org, so envelope data and signer status move between the two systems without a middleware layer to license or maintain. The integration is established by connecting the Docusign and Salesforce accounts through a nominated integration user during setup.
If the outcome can be reached with a template, a merge mapping, a routing rule, a permission set or a Salesforce Flow, it is configuration: no code, upgrade-safe, and maintainable by your own administrators. Once it requires Apex, a Lightning Web Component, or a Docusign Connect listener running your own logic, it is custom development, and it carries test coverage, a deployment process and a named maintenance owner. We place every requirement on one side of that line before quoting it.
Yes. Multiple documents can be combined into a single envelope with role-based routing, which is how lease bundles, KYC packets and multi-entity agreements are normally configured. The work is in defining the roles and the signing order against your actual process, so the packet cannot reach the wrong party out of sequence.
Docusign Connect notifies Salesforce when envelope events occur — sent, delivered, viewed, completed, declined or voided — and Salesforce Flow or Apex acts on those notifications. That is what advances a stage, creates the next task, files the signed document and notifies the owning team automatically instead of someone acting on an email. Configuring those listeners and the logic behind them is typically the largest part of the engagement.
Most engagements run four to eight weeks through process audit, template and routing configuration, and automation build. What moves that range is the number of document types and routing scenarios in scope, not the size of the Salesforce org or the number of licences. A single-document, single-signer flow is a short project; a multi-entity closing packet with internal approvals is not.
Docusign has de-listed the legacy eSignature for Salesforce package and set 16 October 2026 as its end-of-service date, after which the legacy eSignature for Salesforce and eSignature for Salesforce CPQ applications stop functioning. The move is to install the current Docusign eSignature for Salesforce application and use Docusign's migration tool for buttons, templates, users and records. The tool does not re-point your automation, so Flows, Apex, reports and custom fields built against the legacy objects have to be rebuilt and tested — that re-pointing is the real work in a migration.
That is where a large share of our Docusign work starts. A common engagement is auditing an existing configuration, repairing merge-field mappings and broken Flow triggers, taking ownership of an unmanaged template library, and adding the post-signature automation that was never built the first time. It rarely requires starting again from an empty configuration.
Next Step
Tell us what you send, and we will tell you what should be automatic
We will walk your current agreement process, show you where Docusign should be driving stage updates, routing and compliance logging, and say plainly which parts are configuration and which are custom development — before anything is quoted.
Salesforce delivery · Agreement automation · Legacy package migration
