DocuSign Gen for Salesforce generates Word and PDF documents directly from Salesforce records, merging live CRM data into templates your team already recognises. Twopir Consulting designs the data model behind it, builds and governs the Gen templates, wires generation into Flow, and hands the finished document to eSignature. Configuration, custom development and the boundary between them — stated up front.
Trusted by 500+ organizations — including legal, healthcare and professional-services teams running document-heavy processes on Salesforce with Twopir Consulting.
Salesforce Document Automation Practice
Document problems rarely start in the document. They start in the data model, the template library and the approval path behind it. Automating a broken process only makes it produce errors faster.
A rep copies the last proposal, swaps the client name, updates the pricing table and hopes nothing was missed. The same twenty minutes is spent on every deal, and the mistakes are invisible until a customer finds one.
Pricing, legal entity names, terms and dates get typed into documents that were already correct in Salesforce. Every re-entry is a chance to send a customer a number the CRM does not agree with.
Forty near-identical Word files live on a shared drive, each with a different footer, an older price list or a clause legal retired last year. Nobody knows which is current, so everyone keeps their own copy.
A signed agreement waits on whoever owns the template, then on an approver, then on someone to attach it to an email. The deal does not stall on the decision — it stalls on the paperwork after it.
The document is produced in one tool, downloaded, re-uploaded to another for signature, then filed somewhere a third team cannot see. The audit trail ends up spread across three systems and one inbox.
Leadership cannot answer how many agreements went out last month, which variant was used, where documents sit unsigned, or which step adds the delay — because none of it is a record in Salesforce.
DocuSign Gen for Salesforce is a native Salesforce application that generates Word and PDF documents from Salesforce records. An administrator builds a Gen template against a chosen Salesforce object — the template's data source — then adds merge fields from that object and its related objects. When a user generates from a record, Gen merges the live data into the template and produces a finished document without anyone retyping a value.
Two capabilities are what make it more than mail-merge. Dynamic tables pull repeating related records — quote line items, products, schedules — into a table that grows with the data, with sorting and grouping applied. Document rules and conditional logic decide which clauses, sections or whole template variants appear, so one template can serve several regions, entities or contract types instead of forty files on a shared drive.
Gen is installed through DocuSign Apps Launcher and requires a DocuSign eSignature plan, which is the clue to its design intent: it is built for documents that are going to be signed. Generation hands straight to an eSignature envelope, and the signed result comes back to the record. Full product detail is in DocuSign's own Gen for Salesforce documentation.
DocuSign Gen next to the DocuSign products it is most often confused with
| Product | What it does | Choose it when |
|---|---|---|
| DocuSign Gen for Salesforce | Generates Word and PDF documents from Salesforce records using templates, merge fields, dynamic tables and document rules. | The document is assembled from CRM data and then signed. |
| DocuSign eSignature for Salesforce | Sends documents for electronic signature from Salesforce and writes the signed result and signer data back. | You already have the document and need it executed and recorded. |
| DocuSign Negotiate for Salesforce | Adds redlining, version comparison and internal approval on the agreement before it is sent. | Counterparties routinely mark up your paper. |
| DocuSign CLM | Manages the full contract lifecycle — repository, obligations, renewals and advanced routing workflows. | The problem is governing contracts after signature, not producing them. |
Where Gen is the right tool — and where it is not
| Requirement | Gen fit | What we would recommend instead |
|---|---|---|
| Contracts, quotes and agreements that end in a signature | Strong fit | — |
| Output beyond Word and PDF — Excel, PowerPoint, HTML email | Not supported | A broader generation engine such as Conga Composer or Nintex DocGen. |
| No DocuSign eSignature entitlement in the business case | Blocked — Gen requires one | Price the eSignature plan in, or evaluate a generation-only product. |
| Post-signature obligation tracking and renewals | Out of scope | DocuSign CLM, or renewal automation built in Salesforce. |
These are three different engagements with three different scopes. Most teams arrive needing one and discover they need a second — so we say up front which is which, and where configuration stops and custom development starts.
A first DocuSign Gen for Salesforce rollout, from licensing and install through to a team that is generating documents daily without asking an admin for help.
You already own Gen, but template sprawl, slow generation or a rule nobody can explain is holding it back. We rebuild the parts that are failing without restarting the programme.
When the requirement passes what declarative configuration can express, we build it with the Salesforce Apex Toolkit and Flow — and we tell you before we start that it is development, not setup.
The configuration / custom development boundary, stated plainly
| Requirement | Configuration | Custom development |
|---|---|---|
| Merge fields from the record and its related objects | Yes — template setup | Not required |
| Show or hide clauses based on record values | Yes — document rules | Not required |
| Line items in a table that sorts and groups | Yes — dynamic tables | Not required |
| Generate automatically when a stage changes | Partially — Flow orchestration | Usually — invocable Apex |
| Generate, envelope and send in one unattended run | No | Yes — Apex Toolkit |
| Data shaped across objects the template cannot reach | No | Yes — data preparation layer |
Gen supplies the generation engine. These are the pieces we design, build and test around it so it behaves the same on the five-hundredth document as it did in the demo.
The data source object, the relationships the template must traverse, and the fields that have to be populated and trustworthy before generation is switched on.
Word-based templates built to your brand and legal standards, with merge fields, dynamic tables and the structure that keeps a long agreement readable after merge.
One template that serves several regions, entities, languages or contract tiers — with the rule logic documented so a future admin can change it safely.
Generation triggered by a stage change, an approval or a schedule instead of a button — built with Salesforce Flow and, where required, the DocuSign Apex Toolkit.
The path from generated document to internal approval to a routed DocuSign envelope, with the signed file and signer data landing back on the originating record.
Who may build templates, who may generate, and which records each group can generate from — mapped to permission sets, licences and your sharing model, not left at defaults.
Templates tested against the records that break them — empty related lists, long line-item tables, missing signatories, multi-page clause combinations — before users meet them.
A named owner per template, a change process legal will accept, and ongoing support as pricing, clauses, entities and Salesforce releases keep moving.
Most DocuSign Gen implementations that disappoint were configured correctly. They failed on choices made before the first template — about objects, data quality, permissions and where generation is triggered from.
A Gen template is built against one data source object and reaches its related objects from there. Choosing Opportunity over Quote, or a custom Agreement object over either, determines which fields the document can ever see. Changing it later means rebuilding the template.
Gen prints what the record holds. Blank legal entity names, inconsistent address formats and free-text terms all survive the merge and reach the customer. We profile the fields a template depends on and fix or guard them before go-live, not after the first complaint.
Template authoring is an administrative capability, not a user one. We separate the people who may create and edit Gen templates from the far larger group who may generate from them, and map both onto permission sets and DocuSign licence assignment.
A button on a record is the simplest option and often the wrong one at volume. We decide deliberately between user-initiated generation, Flow-triggered generation on a stage or approval, and scheduled batch runs — each has different failure modes and different support costs.
Every new template is a maintenance liability. Conditional document rules let one template absorb variants that would otherwise become separate files, so we set the rule for when a variant earns its own template — and consolidate the ones that never should have.
Generated documents consume Salesforce file storage and become records someone will eventually be asked to produce. We agree where documents are stored, what is retained, what is reportable, and how the generation and signature trail is evidenced.
Six phases, one continuous engagement. A focused first template set usually reaches production in weeks rather than months; scope, template count and how much data work is needed move that date more than anything else. We give you a date after discovery, not before it.
We inventory every document you produce, who creates it, what data it needs and what approval it passes. Most of the eventual saving is identified here, in documents nobody realised were being made by hand.
Data source objects, relationship paths, the variant strategy, the trigger model and the permission design are decided and written down. This is the phase that determines whether the build is reusable or disposable.
DocuSign Apps Launcher is installed and configured, templates are built with their merge fields, dynamic tables and document rules, and legal and brand owners review real generated output — not a mock-up.
Generation is wired into Salesforce Flow and, where the requirement needs it, invocable Apex. The eSignature handoff, the write-back to the record and any downstream automation are built and connected here.
Templates are tested against the edge-case records that break them, users are trained on the version they will actually use, and go-live is monitored so the first week's issues are found by us, not by a customer.
Clauses change, pricing changes, Salesforce releases three times a year. We keep templates, rules and automation current, and extend the build to the next document set once the first is bedded in.
The pattern is consistent: a document assembled repeatedly from data Salesforce already holds, which then needs a signature. These are the ones that pay for the implementation first.
Listing agreements, offer letters, tenancy contracts and disclosure packets generated from the property and contact records, then sent for signature — the workflow behind our Salesforce for real estate engagements.
A branded proposal with a priced line-item table built from the opportunity or quote, so the document and the CRM can never disagree on what was offered.
Master agreements, statements of work and order forms where conditional rules select the right clause set for the region, entity or contract tier on the record.
Engagement letters, KYC forms, data-processing terms and welcome documents produced as one package the moment an account moves to onboarding.
Renewal notices and amendment paperwork generated on schedule from the contract record, so renewals are worked from a date field rather than someone's memory.
Customer-facing invoices and billing schedules produced from billing records on a batch schedule or on demand, and delivered with the same branding as every other document.
Retainers, engagement terms and client correspondence generated from matter records — the document layer of the Salesforce systems we build for law firms.
Scheduled statements, service reports and regulatory summaries assembled from Salesforce data on a fixed cycle, with the generation itself logged as a record.
The gains are operational before they are financial. Each of these is a change we would expect a well-designed implementation to produce — and each is something you can measure in your own org before and after.
Work that was twenty minutes of copying and checking becomes a generation action on the record. The time comes back to the people who were doing it, every single document.
The document says what the record says, because it was built from it. Pricing disputes that traced back to a stale copied template stop happening.
Every document carries the approved branding, the current clause set and the right entity details — including the ones produced by the team that never reads the internal memo.
Generation, approval and envelope creation run as one path instead of three handoffs, so the gap between a verbal yes and an executed agreement narrows.
Because generation happens in Salesforce, volumes, variants, cycle times and stalled documents are dashboard data rather than a question someone has to go and ask.
Doubling document volume no longer means doubling the people who assemble them, which is usually the point at which document automation moves from nice-to-have to funded.
DocuSign Gen is one of several generation engines we implement. The architecture work underneath — data model, template governance, automation and the signature handoff — is the same, and these are the engagements where it has been proven.
Twopir provided Salesforce customisation and integration services to help us build a robust, compliant, and scalable legal operations platform — connecting case management, document processing, and financial systems into one unified workflow. The result was transformative for how we run case-to-cash operations.
Connecting document processing to case and financial systems in one Salesforce workflow.
Across our Salesforce document-generation engagements, property contracts, offer letters and KYC onboarding forms are generated automatically from CRM data. Contract turnaround moves from two to three days down to a few hours, and document errors fall to near-zero because every value comes from the CRM rather than being transferred by hand.
Property contracts, offer letters and KYC onboarding forms generated from CRM data and routed for signature.
More document automation work: Salesforce and iManage document operations · DocuSign integration services · Salesforce integration services
Document generation is a Salesforce architecture problem wearing a document costume. We help growing and mid-market companies solve complex CRM, integration, and business system challenges — and document automation is one of the places that expertise shows up fastest.
The template is the last thing we build, not the first. Objects, relationships, field quality and the variant strategy come first — which is why our templates survive the second and third wave of requirements.
Some requirements are template setup. Some are Flow. Some are Apex. We say which before the estimate, so nothing is discovered halfway through the build and repriced as a change request.
We implement DocuSign Gen, Nintex DocGen, PandaDoc and Conga. That means we can tell you honestly when Gen is the right answer and when its Word-and-PDF output will not carry your requirement.
Generation, approval, signature, write-back and reporting are one workflow, not four vendors' problems. We build and support the entire path, including the Salesforce automation around it.
Clauses, pricing, entities and Salesforce releases keep moving. Template governance and ongoing optimization are part of the engagement, not an upsell after the first template goes stale.
Six phases: discovery of every document you produce today, solution architecture covering data source objects and the variant strategy, DocuSign Apps Launcher configuration and template build, automation through Salesforce Flow or Apex, testing and training, then ongoing support. The configuration itself is rarely the long pole — deciding which object each template hangs from, and cleaning the fields it depends on, usually is.
A focused first template set usually reaches production in weeks rather than months. Three things move that date more than anything else: how many templates are in scope, how much data remediation the templates depend on, and how many approvers have to review generated output. We commit to a timeline after discovery, because a date given before it is a guess.
Yes. Gen is distributed through DocuSign Apps Launcher and requires a DocuSign eSignature plan, and installation needs both DocuSign administrator and Salesforce administrator permissions plus a Salesforce My Domain subdomain for the Lightning components. If signature is not part of your requirement at all, that licensing reality is usually the argument for evaluating a generation-only product instead — we will say so rather than sell around it.
Yes, but it is custom development rather than configuration. Unattended generation is built with Salesforce Flow calling invocable Apex that uses DocuSign's Apex Toolkit, which can generate the document, attach it to an envelope and send it in one run. We scope this as development work, estimate it as development work, and write the tests that come with it.
Gen is built for agreements that route through DocuSign eSignature, and its output is Word and PDF. Conga Composer generates across a wider set of formats including Excel, PowerPoint and HTML email, which matters if your requirement is reporting packs or spreadsheets rather than contracts. Nintex DocGen sits closer to Gen but pairs with Nintex workflow. We implement all three, so the recommendation follows the requirement rather than the licence we would prefer to sell.
That is a common starting point. Low adoption almost always traces to one of four causes: templates built against the wrong data source object, document rules nobody can explain or safely change, fields the template depends on being empty on real records, or a permission model that makes generation awkward for the people who need it. We assess all four and rebuild only the parts that are failing.
Twopir Consulting is a Salesforce Partner and a HubSpot Partner, and we implement DocuSign Gen and DocuSign eSignature on the Salesforce platform. We do not claim a DocuSign partner tier we do not hold. What we bring is 12+ years of Salesforce delivery and a team of 40+ consultants who have built document automation across legal, healthcare, real estate and professional services.
A first conversation is a working session, not a pitch. We look at one real document, the records behind it and the approval it passes, and tell you whether DocuSign Gen for Salesforce is the right engine — and what the implementation would involve if it is.
Salesforce architecture, document automation & integration — Serving: US | Canada | UK | UAE | Australia | New Zealand
