Decide Where the Agreement Lives Before You Connect Anything
Connecting Docusign to one system is a configuration task. Connecting it to five is an architecture decision, and the question that decides whether it works is not technical: which system owns the agreement record, and which ones are merely allowed to read it.
- CRM — Salesforce and HubSpot
- Finance — NetSuite, SAP and billing systems
- Content — SharePoint, Box and Google Drive
Which System Owns the Agreement?
Integrating Docusign with your CRM, ERP and content systems means defining, for each connection, what business problem it solves, what data crosses, and in which direction. The technical work is rarely the hard part. The hard part is deciding which system holds the authoritative agreement record, because every other decision — where status is read, which system triggers what, where the executed document is filed, who resolves a conflict — follows from that one answer.
What happens when nobody decides. Each integration is built by whoever needed it, each treats its own system as the centre, and within two years the CRM, the finance system and the document store hold three versions of the same agreement's status. Nobody trusts any of them, so someone opens Docusign to check — which is the manual step the integrations were built to remove.
Our default position
For commercial agreements the CRM is usually the right owner, because that is where the relationship, the pipeline and the reporting already live. Docusign is the execution system and the source of the audit trail. The ERP consumes executed terms rather than owning them. The document store holds the file for retention, not for status. Finance systems rarely make good agreement owners even where they hold the most valuable data — they are records of transactions, not of relationships.
That is a default, not a rule. Procurement-led organisations, and businesses where legal operations owns the contract estate, often make CLM the owner instead, with the CRM reading from it. What matters is that the decision is deliberate, written down, and the same for everyone.
Each One, With Its Direction Stated
For every integration we write down three things before building: the business purpose, the data that moves, and the direction. An integration without those recorded is the one nobody can safely change two years later, when the person who built it has gone.
The list opposite covers the connections we are asked for most. Anything not listed is generally reachable — the question is whether it warrants a direct integration or belongs behind middleware.
Docusign + Salesforce
Two-way. Salesforce composes and addresses the envelope from record data; envelope and recipient status, the executed document and signer-entered values return to update the record and trigger what follows. The deepest of the standard integrations and the one with the most design decisions — covered on the Salesforce integration page.
Docusign + HubSpot
Two-way. Envelopes are created, sent and tracked from a contact, company or deal record, with HubSpot properties mapped into the document and workflow actions triggered from Docusign events. One design constraint to plan around: deal-based workflows require the template's recipient count to be no greater than the contacts associated with the deal, so association hygiene becomes a prerequisite rather than an afterthought.
Docusign + NetSuite, SAP and finance systems
Inbound on completion. A countersigned order form is the event that starts provisioning, invoicing and revenue recognition, so the executed terms and their structured values pass to finance rather than being re-keyed from a PDF summary. Direction matters here: finance consumes the agreement, it does not own it.
Docusign + SharePoint, Box and Google Drive
Outbound. The executed document and its Certificate of Completion are written to the document store under a folder and naming convention derived from the source record, so the retention policy applies automatically instead of depending on where an individual chose to file it. Status is not read from here — this is the file, not the truth.
Docusign + HR and identity systems
Inbound. The HR system defines who exists and which role they hold; the identity provider authenticates them and drives provisioning, so sending rights arrive and depart with employment rather than with a quarterly licence review. The population for bulk sends such as policy acknowledgements is derived from the same source.
Docusign + ServiceNow and service management
Two-way. Where agreement requests already arrive as tickets, the request is the intake, the approval chain is the existing one, and the agreement status returns to close the loop. Often the lightest-touch integration available, because the process it needs already exists.
Docusign + middleware
Broker. Past roughly four systems, point-to-point integrations stop being cheaper than a broker. Middleware gives one place to see what ran, one place to retry a failure, and one place to change a mapping — at the cost of a platform to license and govern. We size that trade honestly rather than defaulting to it.
What Moves, and Which Way
This table is the artefact we produce in design and hand over at the end. It is short, and having it written down is what makes the estate maintainable by people who were not there when it was built.
| System | Direction | What crosses | Consumed by |
|---|---|---|---|
| Salesforce | Both | Out: recipients, merge values, template selection. In: envelope and recipient status, executed document, signer-entered fields. | Sales, RevOps, forecasting |
| HubSpot | Both | Out: contact, company and deal properties. In: envelope events driving workflow actions and deal progression. | Sales, marketing operations |
| NetSuite / SAP | Inbound | Executed terms, effective and end dates, pricing, signed document reference. | Finance, billing, revenue recognition |
| SharePoint / Box / Drive | Outbound | Executed document and Certificate of Completion, with metadata for folder and naming. | Legal, records management, audit |
| HRIS / identity provider | Inbound | User identity, role and employment status; authentication and provisioning. | Docusign account administration |
| ServiceNow | Both | Out: request detail and approval outcome. In: agreement status to close the ticket. | Shared services, procurement |
Two rules we hold to when filling this in. Only one system is ever the source of truth for a given field — where two could write it, one is chosen and the other reads. And every inbound connection has a named consumer; if no team can be named as reading the data, the integration should not be built, however easy it would be.
Connected Work
Three Systems, Three Different Answers?
Integration estates get this way gradually. Each connection was reasonable when it was built; the problem is that no two were designed together. The fix usually is not rebuilding them — it is deciding ownership, then adjusting the few connections that contradict it.
A review produces the direction table above for your estate, plus a list of the specific contradictions worth resolving first.
Relatable? We should definitely talk.
What we'll cover:
From CRM and integrations to custom apps and complex system architecture — we help you scale without chaos.- Identify revenue leaks across CRM, integrations, and GTM
- Design and optimize complex systems (CRM to Custom Apps)
- Apply practical AI to improve operations and pipeline conversion
- Eliminate silos and build a unified revenue system
- Assess GTM performance and key bottlenecks
- Align teams with clear processes and ownership
- Define a scalable RevOps model
- Improve forecasting and reporting
- Review your HubSpot/Salesforce setup for scale
