The numbers drift from the record
Someone edits over last quarter's version. The document says one thing, the CRM says another, and whichever the customer received is now the version that matters commercially.
Salesforce · Document Generation
Stop rebuilding documents that your CRM already knows.
Every quote, proposal, statement and agreement your team retypes is data that already exists in Salesforce. Twopir Consulting helps you work out which approach actually fits your volume, complexity and governance needs — then designs the template strategy and builds it. Including telling you when Salesforce alone is enough.
Trusted by 500+ organizations — including legal, healthcare and professional services teams whose document volume outgrew the way they were producing it.
Document Automation Coverage
- Salesforce Partner
- Tool Selection
- Template Strategy
- Conditional Content
- E-Signature
- Bulk & Scheduled Runs
- Storage & Audit
- Brand Governance
Manual documents cost more than the time they take
The hours are the visible cost and usually the smallest one. These are the expensive ones.
Turnaround becomes a deal risk
A proposal that takes two days to produce is two days a competitor has. The cost is not the effort — it is the deals that cooled while the paperwork caught up.
Brand and legal consistency quietly erode
Forty versions of a document in circulation, each slightly edited. Nobody can say which wording is current, and a compliance change means finding all forty.
There is no evidence of what was sent
The document was emailed from someone's client. Salesforce holds no copy, no timestamp, no recipient. That is precisely the question an audit or a dispute asks first.
Skilled people are doing formatting
Lawyers adjusting tables, salespeople fixing headers, analysts pasting figures. The salary cost of manual document work is rarely in the business case and is usually the largest number in it.
It does not scale, so growth makes it worse
Twice the volume means twice the effort, because nothing about the process improves with repetition. The breaking point arrives exactly when the business is doing well.
Native Salesforce, or a document platform
Document generation is the work of producing accurate, on-brand documents from CRM data without anyone rebuilding them by hand. The first decision is not which vendor — it is whether you need one at all.
| Requirement | Native Salesforce | Document platform |
|---|---|---|
| Data from one record | Covered. | Covered — not a reason on its own to buy. |
| Data across related objects and reports | Limited — this is usually the first constraint teams hit. | Core capability. Reports and cross-object queries feed the merge. |
| Layout and brand control | Basic. | Full control, with conditional content doing the variation. |
| Output in Word, Excel, PowerPoint, PDF | Restricted. | All four, from one template family. |
| Signature as part of the flow | Needs a separate tool and a separate hand-off. | Attaches to the generation step directly. |
| Bulk or triggered generation | Build it yourself. | Scheduled and event-driven runs are product features. |
| Honest verdict | Enough for a small number of simple, low-volume documents. Genuinely enough — and cheaper. | Earns the licence once two or more rows above are real constraints for you. |
Where Conga fits
Conga Composer is the option we most often recommend for Salesforce-native document generation, and it is the one we implement most. It generates documents from Salesforce data using templates in Word, Excel, PowerPoint and PDF, then delivers, stores or routes them for signature.
But the decision should follow the four questions, not the other way round. If you have already decided on Composer, the build detail is on Conga Composer implementation — this page is for the decision that comes before it.
The decision that outlives whichever tool you pick
Every document programme we have rescued failed the same way: one template per variant, multiplying until nobody could maintain the set. The tool did not cause it and changing tools will not fix it.
One Set, Not Forty Files
Variation expressed as conditions inside a governed set rather than as separate documents. A legal or brand change becomes one edit instead of a search-and-replace exercise.
- Grouping near-duplicates into template families
- Conditional sections driven by the data
- Naming, versioning and ownership conventions
- A retirement path for the old set
- Governance that survives the next deadline
Getting the Data There
Most "the tool cannot do this" problems are data problems. What the document needs, which objects hold it, and whether the person running it can even see those fields.
- Mapping every value on the document to a source
- Related-object and cross-object data reach
- Field-level security and profile testing
- Handling missing and null values deliberately
- Performance at the volumes you actually have
Output, Delivery & Storage
What format, sent how, stored where, and logged against what. The half of the design that decides whether the process is auditable a year later.
- Format choice per document purpose
- Delivery method and templated covering email
- Storage destination and naming convention
- Write-back and activity logging on the record
- Retention and access policy alignment
Signature in the Flow
Signature designed as a step rather than an errand, with completion coming back to the record so downstream dates are calculated from the right source.
- Signature routing and recipient design
- Reminder and expiry behaviour
- Completion write-back to the record
- Executed copy storage and audit trail
- Native or existing e-signature platform
Volume & Timing
On demand, fired by an event, or run in bulk on a schedule. The pattern changes the design substantially, and platform limits bind sooner than most teams expect.
- On-demand versus triggered versus batch design
- Volume projection and limit planning
- Failure and retry behaviour for unattended runs
- Monitoring so silent failures are not silent
- See automation & workflow services
Assessment & Business Case
Before any of the above. What you produce today, what it costs, what it would take to automate, and whether the answer is a platform, native functionality, or a better process.
- Inventory of documents actually produced
- Effort and error-rate baseline from your team
- Complexity scored against the four questions
- Recommendation with the reasoning shown
- A recommendation of "no tool needed" if that is true
Four patterns worth automating first
If you are deciding where to start, start where volume meets consequence. These four recur across every industry we work in.
Quotes & proposals
High volume, directly revenue-linked, and the place where drift between the document and the record costs real money. Usually the fastest payback and the easiest business case to make internally.
Client-facing legal documents
Engagement letters, notices, statements. Consequence is high and consistency matters more than speed — which makes conditional content and version control the important capabilities rather than raw throughput.
Internal reporting packs
Board reports, executive summaries, period reviews assembled from many reports. Often the largest single time saving, because the current process is one analyst and several days of copy-and-paste.
Scheduled correspondence
Statements, renewal notices, reminders. Individually trivial and collectively enormous, and the pattern where bulk and scheduled generation replaces a recurring manual task entirely rather than just speeding it up.
What automation actually changes
Legal Document Automation
Document generation on Salesforce · Twopir Consulting engagement
A legal team generating client-facing documents by hand from Salesforce data, with no reliable record of which version went out. We replaced ad-hoc files with a governed template set, made Salesforce reports and queries the single data source, and wrote generated output back to the matter record with its delivery logged.
The change people noticed was not speed alone — it was that the document on the record and the document the client received became the same object, which is what made the process auditable.
Read the full case studyHow widely this is already done
Figures reported by Conga about its own install base
Conga reports that more than 8,000 customers use Composer to create over 10 million documents every month, and that Composer was named the leader in the G2 2024 Grid for Salesforce CRM Document Generation, scoring highest for both market presence and customer satisfaction.
These are Conga's figures about Conga's customers, not Twopir outcomes. We cite them because they answer a fair question when you are making the case internally: whether automating documents out of Salesforce is an established practice or an experiment.
Conga's product pageWe will tell you not to buy anything
We help growing and mid-market companies solve complex CRM, integration, and business system challenges, and we work with enterprise organizations facing the same problems at larger scale.
We are not reselling a licence
Our recommendation follows the four questions. If native Salesforce covers your requirement, that is the advice you will get, and it costs you less than any alternative.
Template strategy before tool choice
The one-template-per-variant failure happens on every platform. Getting the strategy right is what determines whether the programme is maintainable, and it transfers whichever tool you choose.
We look at the data model first
Most "the tool cannot do this" conclusions are a missing relationship or a permission issue. Our document work sits inside a Salesforce practice, so we diagnose at that layer.
We design the evidence trail
What was sent, to whom, when, and which version. It costs almost nothing at design time and cannot be reconstructed later, which is why it is in scope from the start.
We can build what we recommend
The assessment is not a report that ends at a recommendation. If the answer is a platform, we implement it; if it is native functionality, we configure that instead.
Answers before the first call
Sometimes Salesforce is genuinely enough. If you need a small number of simple, low-volume documents with straightforward layouts drawing on a single record, native functionality may cover it at no extra licence cost. A dedicated platform earns its place when documents must pull from multiple related objects or reports, when layout and brand control matter, when output has to span Word, Excel, PowerPoint and PDF, when volume demands batch or triggered generation, or when signature and storage have to be part of one flow. Two or more of those being real constraints is usually the threshold.
By answering four questions before looking at any vendor: how much data the document needs and from how many objects, how much the content varies and whether that variation is data-driven, what has to happen after generation in terms of signature, storage and audit, and how many documents get produced and on what trigger. Those answers narrow the field quickly, because the tools differ most in data reach, output formats and how automation is handled. Doing it the other way round — shortlisting vendors and then writing requirements — is how organizations end up with a licence that does not fit the hard case.
Usually not. In our experience the two most common causes are a template set that multiplied instead of using conditional content, and a data problem — a relationship that does not exist, a field that is empty on half the records, or field-level security hiding values from the user running the generation. Both present as "the tool cannot do what we need" and neither is fixed by changing tools; you would rebuild the same design on a new platform. We would rather audit what you have than sell a migration.
Yes, and designing it as one flow rather than two steps is most of the value. The document is generated, routed to the right recipients in the right order, and — the part that gets missed — the completion event, the executed copy and the audit trail come back to the CRM record. Without that return path the signature closes in the signing platform and your CRM still says "sent", which means every downstream date and renewal calculation is running from the wrong source. Conga Sign works natively; DocuSign for Salesforce integrates through a connector where you have already standardised on it.
With a governance rule and an owner, because it is a process problem rather than a technical one. The technical half is straightforward: variation belongs in conditional content driven by the data, so a new region or product tier changes a condition rather than creating a file. The process half is that somebody has to own the set and a new template has to be a decision rather than a default. Every set we have seen sprawl did so under deadline pressure, with each individual copy being the reasonable choice at the time.
An inventory of the documents you actually produce — which is usually more than anyone expected — with each scored against the four questions, a baseline of current effort and error rate taken from your own team rather than from a benchmark, and a recommendation with the reasoning shown so a budget holder can evaluate it rather than take it on trust. If the recommendation is that native Salesforce functionality covers you, it will say that. It is scoped and priced as its own piece of work, and you keep it whether or not you go further.
Start Here
Tell us which document costs you the most time
Bring us one document your team rebuilds by hand. We will work through the four questions with you and tell you what it would take to automate it — including whether Salesforce already covers it and you should spend the budget elsewhere.
Serving: US | Canada | UK | UAE | Australia | New Zealand
