Switching Docusign eSignature on takes an afternoon. Deciding which documents become templates, who signs in what order, what identity check each agreement needs, and what Salesforce should do the moment an envelope completes is the actual project. We plan, configure, integrate and support that work end to end.
Trusted by 500+ organizations — including agreement-heavy legal, real estate and professional-services teams running their contract process on Salesforce with Twopir Consulting.
What We Deliver On Docusign eSignature
Docusign eSignature consulting and implementation is the work of designing, configuring and connecting a Docusign account so that every agreement a business sends follows a defined path — the right template, the right signers in the right order, the right identity check, and a recorded result that lands back on the record it came from.
Three things are easy to blur, so they are worth separating. Docusign supplies the platform: envelopes, templates, recipient routing, signer authentication, the Certificate of Completion and the Salesforce package that connects the two. Twopir Consulting supplies the design and the build: we decide with you which documents become templates, how they map to your Salesforce objects and fields, who signs and approves in what order, what happens automatically after completion, and who is allowed to send what. What you end up with is a signing process your team can run without instructions, your admins can extend without calling us, and your auditors can follow without assembling anything by hand.
We help growing and mid-market companies solve complex CRM, integration, and business system challenges, and we work with growing, mid-market, and enterprise organizations that need the same thing at larger scale. This page covers eSignature specifically. If the question is broader — repository, generation, obligations, orchestration — start with Docusign consulting and implementation across the full suite.
Almost nobody arrives with "we need eSignature". They arrive with a contract stage that stalls, a signed document nobody can find, or an audit request that takes three days to answer. These are the six patterns behind most of them.
Reps open a separate Docusign inbox to find out whether a contract came back, then update the Opportunity by hand. Deals sit in "Contract Sent" for days because the system of record has no idea what happened, and nobody owns the follow-up.
Names, entities, prices and dates get typed into the document or copied from the wrong record. Every manual edit on a legally binding agreement is a commercial and compliance exposure, and the error is usually found after signature rather than before.
A lease packet needs the tenant, then the guarantor, then the asset manager, with legal copied and finance copied only above a threshold. When that order is a habit rather than configuration, agreements reach the wrong person and come back unsigned.
Eighty templates, nine of them near-duplicates, and nobody certain which is current. Senders pick by memory. A wording change means editing the same clause in six places and missing two, which is how an outdated term reaches a signed page.
A completed envelope should close the stage, file the document, create the onboarding task and notify the next team. Instead someone opens it, reads it, and starts the next step manually — so the time saved on signing is spent again on coordination.
Compliance asks who signed what, when, under which version, and with what identity check applied. Docusign records all of it — but if the certificate is not attached to the record it belongs to, answering still means someone exporting and stitching.
These are three different pieces of work for three different situations, and they are priced and staffed differently. Knowing which one you are in is usually the first useful outcome of a discovery call.
You are standing Docusign eSignature up for the first time, or replacing a signing tool you have outgrown. This is a full build: the account is designed before the first envelope goes out, not after the first complaint.
Docusign is already live and is not doing what it should. This is the most common way engagements start with us: the account works, but it was switched on rather than designed, and it has drifted since.
The requirement has passed what point-and-click configuration expresses. This is development work, scoped as development work, and we will tell you when you have crossed that line rather than quietly billing configuration hours against it.
| What you want to do | Native configuration | Custom development |
|---|---|---|
| Send an agreement from a Salesforce record with its data already merged in | Covered — a Docusign button on the object plus a merge-field-mapped template | Not required |
| Bundle several documents for several signer roles in a set order | Covered — templates with recipient roles and routing order in one envelope | Not required |
| Update the Salesforce record and attach the signed PDF when signing completes | Covered — writeback, with Docusign Connect for Salesforce enabled on the account | Not required |
| Verify a signer with a government-issued photo ID before they see the document | Covered — Docusign ID Verification applied per recipient, licensing permitting | Not required |
| Build the envelope at runtime because the documents vary with the record | Partly — only if the variations reduce to a fixed set of templates | Yes — Apex Toolkit, so the envelope is composed in code |
| Let a customer sign inside your own portal or application, never leaving it | No | Yes — embedded signing through the eSignature REST API |
| Drive multi-object automation and external filing off envelope events | Partly — simple stage and field updates are configuration | Usually — Connect listeners with Flow, and Apex past a certain complexity |
These are Docusign's capabilities, not ours. The work is knowing which of them your process actually needs, and setting them so they hold when volume and staff turnover arrive.
Templates pull recipient, price, date and entity values straight from Salesforce fields. We decide which fields are safe to merge and which need a guard before they ever reach a signed page.
When a signer changes a merged value, Docusign can update that Salesforce field on completion, upload the executed document to the record, and set the stage. We map which of those should happen, and which should not.
Each recipient can sign, approve, receive a copy or be asked for an attachment, in a defined order, with conditional routing and document visibility where an agreement should not be fully readable by every party.
Access codes, SMS one-time passcodes and ID Verification against a government photo ID or European eID. We set the requirement per document type, so a routine order form is not gated like a mortgage packet.
One document to a long list of recipients, each receiving their own copy to sign. Built for policy acknowledgements, annual re-papering and portfolio-wide notices rather than one-by-one sending.
Self-service documents a signer starts themselves, with no sender involved, and the collected data pulled into the systems behind it. Useful anywhere the trigger is the customer rather than your team.
Chase logic that runs without anyone remembering, expiry rules that stop stale envelopes being signed months later, and a retention and disposition policy your records team can actually defend.
Docusign records every view, send, sign and decline and issues a Certificate of Completion. Connect turns those same events into the downstream automation your CRM runs the moment an envelope completes.
Capability names and behaviour on this page follow Docusign's own documentation — the Docusign eSignature for Salesforce administrator guide is the reference we configure against. Licensing determines which of these your account can use, and confirming that is part of discovery.
An eSignature account is only as useful as what it is wired into. These are the four connections that decide whether signing is a step in your process or a detour around it.
The core connection, and the one most engagements are really about. Docusign's Salesforce package puts a send action on the objects your team already works in — Opportunity, Quote, Contract, a custom object, a Financial Services Cloud account — so nobody leaves the CRM to get a document signed, and the CRM is never the last to know it was. Deeper detail on this connection sits on our Docusign Salesforce integration services page.
Salesforce → Docusign: recipient, entity, pricing and date values merged into the template. Docusign → Salesforce: envelope status, signer-entered values, the executed PDF and the Certificate of Completion, written back to the originating record.
Where the document is a priced quote, the signature belongs at the end of the quoting step rather than in a separate tool afterwards. Docusign eSignature works with Salesforce CPQ so a quote can be created and sent for signature without leaving CPQ — which matters most when pricing is still moving and a re-quote must not orphan a live envelope.
CPQ → Docusign: the generated quote document plus line-level and total values. Docusign → CPQ and Sales Cloud: execution status against the quote and the opportunity it belongs to.
Signing assumes a document already exists. When yours is assembled from Salesforce data — through Docusign Gen for Salesforce, Conga Composer or Nintex DocGen — generation and signature have to be designed as one handoff. Getting that seam wrong is what produces two systems of record for the same agreement.
Salesforce → generation engine: merge data and template selection. Generation → Docusign: the assembled document with signature anchors already placed. Docusign → Salesforce: the executed version, filed once.
A signed agreement is the trigger for everything after it: invoicing, provisioning, onboarding, filing. Envelope completion events can start that chain in your finance or ERP system and place the executed document in the repository your records policy names, rather than leaving it only in Docusign. Where that spans several systems, our Docusign integration with CRM and business systems work covers the wider map.
Docusign → downstream: completion event, executed document and signer metadata. Downstream → Salesforce: billing, provisioning or matter status returned to the record, so one place still answers "where is this agreement".
Most implementations move through process audit, template configuration and automation build within four to eight weeks, depending on how many document types and routing scenarios need to be configured. Complex CLM-adjacent work, heavy custom development or a multi-region rollout runs longer, and we say so at proposal rather than at go-live.
We inventory every document type you send: volume, who signs, in what order, what data it carries, what has to be true before it goes out and what must happen after it returns. Almost every bad eSignature build traces back to this list never being written down.
If there is an existing account, we read it before we change it — templates and their duplicates, senders, permission profiles, routing, integration points and licence position. This is where we find the six near-identical templates and the sender group nobody has reviewed in three years.
We design the account and the Salesforce side together: which objects carry the agreement, which fields merge, how groups and permission profiles map to your org chart, what identity each document type requires, and where the data model needs to change before configuration starts rather than after.
Templates, merge mapping, recipient roles, routing, branding, reminders and expirations in Docusign; package setup, send actions, Flow triggers, Connect listeners and writeback in Salesforce. Custom development, where the requirement needs it, is scoped and built as its own workstream.
We test the paths that break in production, not just the happy one: a declined envelope, a signer who edits a merged value, a routing order interrupted halfway, a sender without permission. Then we train senders and admins separately, because they need different things.
A phased rollout by team or document type, hypercare while real volume arrives, then ongoing optimization as new document types appear. We document the template architecture so your admins extend it themselves — and stay available through Docusign support and managed services when you would rather we did.
A lease, its disclosures and its addenda bundled into one envelope with tenant, guarantor and asset manager routed in order, triggered from the deal record. Our Salesforce for commercial real estate work is where most of these start.
The envelope sends when the Opportunity reaches contract stage and the stage advances only when Docusign confirms full execution — which closes the gap between a deal being signed and a deal being recorded as signed.
Account agreements, identity forms and disclosures assembled into a single signing experience with the identity check set to match the regulatory requirement, and completion starting the first onboarding task automatically.
Re-papering driven from the dates already in Salesforce rather than from a spreadsheet someone maintains, with Bulk Send for portfolio-wide changes and a record of which version each counterparty actually signed.
Engagement terms sent the moment a matter is accepted, routed through the responsible partner, and filed against the matter record with the certificate attached. Adjacent to our Salesforce for law firms practice.
The documents nobody budgets for and everybody chases. PowerForms and Bulk Send take most of this off individual inboxes, and a single permission model stops nine teams each inventing their own template set.
License agreements used to move through email and manual drafting at every step. Now the system generates, routes, and signs them — and the rent roll stays current without anyone re-entering data.Twopir Project Lead Enterprise real estate client · United States · 2026 Salesforce · Conga · Docusign
Agreements were drafted by hand, routed through email before they ever reached Docusign, and rent rolls were updated one record at a time. We built a Salesforce-native workflow that generates, routes, signs and renews agreements, with routing order wired directly into Docusign and a custom Apex batch class keeping rent rolls current.
These are the changes a well-designed eSignature implementation produces. How much each one is worth depends on your volume and your starting point, which is what an assessment is for — we would rather scope that with you than publish a number we cannot evidence.
Sent, viewed, completed and declined are visible on the record itself, so the question "where is that contract" stops being a task someone performs.
Merged fields remove the retyping that puts the wrong price, party or entity name on a legally binding page — which is a compliance improvement before it is an efficiency one.
Named owners, version control and a naming convention mean a clause change happens once, in one place, and everyone sending is sending the current document.
Stage updates, filing, task creation and notifications fire off Connect events rather than off somebody remembering to act once a deal comes back signed.
The Certificate of Completion and full envelope history attach to the record they belong to, so a compliance request is a search rather than a project.
Documented architecture, permission profiles that mean something and admins who were trained to extend it — so growth and staff turnover do not reset the system.
Templates built without understanding how your documents actually move just relocate the manual work into Docusign. The document inventory comes first, every time.
Adding a send action to an object is an afternoon. The Flow logic, Connect listeners, writeback mapping and stage handling around it are the actual project — and the part most implementations skip.
Most signing problems are really data-model problems. Because we build the Salesforce side as well, we can say when the right fix is a field, an object relationship or a Flow rather than another template.
Some requirements need the Apex Toolkit or the REST API, and some do not. We name that boundary in the proposal — see the comparison table above — instead of discovering it halfway through the build.
A new document type next quarter should not mean a new statement of work. We document the template and permission architecture so your team extends it, and stay available when you want us to.
It covers discovery of every document type you send, assessment of any existing Docusign account, solution architecture across both Docusign and Salesforce, configuration of templates, merge fields, recipient roles, routing and identity requirements, the Salesforce integration and post-signature automation, testing, user training, deployment, and support afterwards. Custom development is scoped as its own workstream where the requirement goes beyond configuration.
Most implementations move through process audit, template configuration and automation build within four to eight weeks, depending on how many document types and routing scenarios need to be configured. Engagements involving significant custom development, a migration from another signing platform, or a phased multi-region rollout run longer, and we scope that at proposal rather than at go-live.
No. Docusign publishes a managed package for Salesforce on the AppExchange that connects the two directly, and Docusign Connect for Salesforce handles the events that write envelope status, signer-entered values and the executed document back to the record. Middleware only enters the picture when the agreement process also has to reach systems outside Salesforce, such as an ERP or a separate document repository.
Yes, and this is how a large share of our Docusign engagements begin. A typical remediation audits the live account, consolidates a template library that has grown duplicates, corrects merge-field mapping where the wrong Salesforce field is reaching the document, repairs broken send actions and Flow triggers, and adds the post-signature automation that was never built the first time. It is usually faster and cheaper than starting the account again.
Sending from a record with merged data, bundling multiple documents for multiple signer roles in a set order, applying an identity requirement, and writing status and the signed document back to Salesforce are all native configuration. Development starts when the envelope has to be assembled at runtime from variable record data, when signing must be embedded inside your own portal or application, or when envelope events drive automation across several objects with real conditional logic. The first group is Apex Toolkit and REST API work; the second is Flow and Apex around Docusign Connect.
Yes. A single envelope can carry several documents with recipients assigned distinct roles — sign, approve, receive a copy, provide an attachment — in a defined routing order, with conditional routing and document visibility where not every party should see every page. This is how lease bundles, KYC packets and multi-entity contracts are configured, and designing that routing correctly is usually a larger part of the project than building the templates.
Docusign publishes ISO 27001, SOC 1 Type 2 and SOC 2 Type 2 certifications, states PCI DSS compliance, and lists FedRAMP authorization for its federal offerings, alongside ESIGN and UETA compliance in the United States and eIDAS-based signature types in the European Union. Every completed agreement carries a time-stamped audit trail and a Certificate of Completion. Certifications are a starting position, not a compliance programme: which identity check each document type requires, who is permitted to send it, and how long the executed document is retained are configuration decisions, and they are part of what an implementation has to settle. Confirm current certification scope against Docusign's own certifications page for your region and plan.
Bring the document types you send most and we will walk through where Docusign eSignature should be doing the templating, the routing, the identity check and the writeback — and which of the three engagements you are actually in.
Salesforce architects who implement Docusign — not a reseller
