Implementations fail on the unglamorous parts: an approval path nobody documented, a sandbox that does not match production, users trained on a process that changed the week before launch. This page sets out exactly how we run a Docusign implementation, what each phase produces, and what it needs from your team.
A Docusign implementation is a delivery engagement that takes an agreement process from a documented current state to a configured, tested and adopted one. Concretely, it covers account and permission architecture, template and routing build, integration with the systems that hold the data, scripted testing against real agreement types, user enablement and a supported stabilisation period. Provisioning the account is not part of the difficulty; deciding how it should be structured, and getting people to use it that way, is.
The distinction this page draws with the Docusign consulting and implementation pillar: the pillar covers what our practice does and how to choose a partner. This page is about the engagement itself — its phases, its deliverables, its duration, and what it will take from your people while it runs.
Duration is driven by four things, in this order of impact: how many distinct agreement types are in scope, how much approval logic sits in front of the signature, how many systems the agreement has to touch, and how much legacy content has to be migrated. A single-agreement-type eSignature rollout with one CRM integration is a materially different engagement from a CLM programme with a clause library and ten years of contracts to bring across.
We give a duration at the end of discovery, not before it, and we give it as a range with the assumptions attached. A date quoted before anyone has seen the approval matrix is a guess presented as a commitment.
Implementations stall on client-side availability more often than on anything technical. The table below is the honest version of what we will need and roughly when, so it can be planned for rather than discovered.
| Phase | Who we need | What they do |
|---|---|---|
| Discovery | Process owners, legal, one or two senders who do the work daily | Workshops, plus honest answers about the exceptions and workarounds that are not in the written procedure. |
| Solution design | Process owner, IT or CRM owner, whoever signs off spend | Review and approve the design document and the licence position. This is the decision gate — changes after it cost time. |
| Configuration and build | CRM administrator, security or IT for access and SSO | Provide environment access, approve field and object changes, supply final document content from legal. |
| Testing and UAT | Real senders and approvers from each in-scope team | Run the scripted cases end to end and sign real test envelopes. This is the heaviest client-side phase, and the one most often under-resourced. |
| Rollout | Team leads, plus an internal owner for the account | Attend role-based training, schedule their teams, and take handover of the administrator runbook. |
| Hypercare | The named internal administrator | Triage first-line questions with us alongside, so the knowledge transfers rather than staying with the consultant. |
Every phase ends with something you can read, review and reject. That is deliberate: it is the mechanism that stops an implementation drifting, and it means a change of direction costs a document rather than a rebuild.
Phases compress when scope is narrow. They do not disappear — a first rollout that skips scripted testing simply moves the testing to the users, after go-live, without a defect log.
We follow one real agreement of each type from request to filing, and record what actually happens rather than what the procedure says. Exceptions get equal billing: the 15% of cases that break the standard path are usually where the implementation will fail if they are not designed for.
Output — current-state map, agreement type inventory, requirements registerThe target design: account and permission structure, template architecture, routing and conditional logic, integration points with direction of data flow, and identity requirements per agreement type. Plus which Docusign capabilities that design requires, with the reasoning, so the licence conversation is informed.
Output — solution design document, integration specification, licensing recommendationBuilt in a demo or sandbox account, never directly in production. Account structure, permission profiles, brands, template library, routing and field logic, then integration work against Salesforce, HubSpot or your own application. Custom development is a last resort, used where configuration genuinely cannot reach.
Output — configured non-production environment, build documentation, promotion planScripted cases per agreement type covering the happy path, the exceptions, and the failure paths — a declined signature, a corrected recipient, an integration that is briefly unavailable. Business users run them and raise defects; we fix and re-test before anything is promoted.
Output — test scripts, executed evidence, defect log with resolutionsPromotion to production, user provisioning against the permission model, and role-based training — senders, approvers and administrators get different sessions because they need different things. Staged by team or agreement type where the change is significant.
Output — live production configuration, trained users, administrator runbookA defined period of close support while real volume flows, with your named administrator working alongside us rather than behind us. It closes with a review against the original process map and a prioritised backlog drawn from what live usage exposed.
Output — stabilised process, knowledge transfer complete, improvement backlogA replacement is not a fresh implementation with extra steps. It carries three problems a greenfield build does not: in-flight agreements, a signed back catalogue, and users with habits.
Envelopes sent on the old platform cannot be moved mid-flight. We agree a cutover date after which nothing new is sent on the incumbent, and let the existing queue drain — running both platforms briefly is the cheapest option available.
Executed agreements and their audit certificates need to remain retrievable for as long as your retention policy requires. We decide deliberately whether they move into Docusign, stay where they are with a pointer, or go to a document store — and write the decision down.
People who already send documents successfully have no natural motive to change. Enablement targets what is different rather than teaching e-signature from scratch, and the new path has to be at least as fast as the one it replaces or it will be routed around.
Where the incumbent is embedded in Salesforce, the migration also touches the CRM: old buttons, flows and fields referencing the previous package have to be retired deliberately rather than left in place to confuse the next administrator. That work is covered on the Docusign Salesforce integration page.
The most useful first conversation is not a feature list. It is one agreement, followed end to end: who asks for it, what they have to fill in, who changes it, who approves, who signs, and what is supposed to happen afterwards that currently does not.
Bring that, and we can tell you in one session whether this is a configuration job, an integration job or a process problem that no amount of Docusign will fix.
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.
