Teams reshape their process to fit the default Docusign setup far more often than they need to — usually because nobody showed them what the platform can already be configured to do. This page is about that gap: what conditional routing, dynamic fields, branding and embedded signing can reach without code, and where code genuinely starts.
Docusign customisation covers everything between the default account setup and a custom-built integration: conditional recipients and routing, field logic and formulas, branded signing experiences, embedded signing inside your own interface, localised content, and extensions built against the Docusign APIs where nothing else reaches. The discipline is not doing all of it — it is establishing, for each requirement, the cheapest rung of the ladder that satisfies it.
Why the ladder matters. A requirement met by configuration can be changed by your administrator on a Tuesday afternoon. The same requirement met by code needs a developer, a test cycle and a deployment, and it has to be revisited every time Docusign or the connected platform changes. Custom code is sometimes exactly right. It is just rarely the first right answer, and it is never free after the build.
Requests usually arrive as solutions rather than problems — "we need a custom button that does X". We ask what the person is trying to achieve, whether the platform already does it, whether the process could reasonably change instead, and what maintaining the customisation will cost over three years. A useful proportion of requests dissolve at the second question.
The ones that survive get built at the lowest rung that works, documented, and handed to someone who can maintain them. That last part is what separates a customisation from a liability.
Recipients who appear in the routing order only when a condition holds — a second approver above a value threshold, a witness for certain document types, a regional signatory. Configured as rules on the envelope rather than assembled by the sender each time.
Fields that appear based on what a signer has already answered, values calculated from other fields, and validation that prevents a document coming back incomplete or internally inconsistent — rather than someone noticing afterwards.
Docusign Brands control what the signer sees — logo, colours, the wording of notification emails. Where a group operates several trading entities or regions, each gets its own brand so the signer sees the counterparty they expect rather than the parent.
The signer completes the document inside your portal or application rather than following an email link — appropriate for account holders already authenticated in your product. Requires API work, so it sits higher on the ladder than it first appears.
Buttons and components that compose an envelope with the right template, recipients and values already resolved, so a sender confirms rather than assembles. On Salesforce this is Apex Toolkit work; on HubSpot it is field mapping and workflow configuration.
Where the requirement genuinely exceeds configuration: a listener that acts on envelope events in a bespoke way, a workflow step that calls an internal system, a process no connector models. Built with the same care as any production service.
Real requests we are asked to build, and the recommendation we usually make. The third column is the one worth reading — the cost that shows up later rather than in the quote.
| The request | Usual approach | What it costs later |
|---|---|---|
| "A second approver above a value" | Conditional recipient on the template, driven by a field from the source record. | Nothing. The threshold is a value an administrator edits. |
| "Our own logo and colours for signers" | A Docusign Brand per entity, selected from the record at send time. | Nothing beyond keeping brand assets current. |
| "Sign without leaving our portal" | Embedded signing through the API, with return states handled explicitly. | Real. It is application code with its own release cycle and failure paths. |
| "A field that calculates a total" | A formula field on the document, or the value merged in at generation. | Nothing, provided the source of the number is decided and documented. |
| "Route differently for each of our eleven regions" | Usually a sign that routing should be driven by data rather than by eleven templates. Often a template consolidation, not a customisation. | Avoided entirely — eleven near-identical templates is the expensive version. |
| "Match the paper process exactly" | Challenge it first. Paper processes encode constraints that no longer apply, and reproducing them faithfully preserves the constraint. | Potentially high, and entirely avoidable if the question is asked early. |
A surprising share of "Docusign cannot do that" turns out to mean "the person who set it up did not know it could". Conditional routing, per-entity branding and field logic are all standard capability, and all three are routinely absent from accounts that needed them from the start.
Describe the requirement and we will tell you which rung of the ladder it sits on — including the cases where the honest answer is that the process should change instead.
