One Template Per Variation
Forty templates that differ by a paragraph. A wording change means forty edits, thirty-nine of which get done. The difference should have been a conditional block driven by a field, not a separate file.
Formstack Documents implementation is the design and build of the templates, merge mappings and delivery routes that turn structured data into finished documents. Twopir Consulting builds that layer the way you would build software — with a template architecture, a field dictionary, version control and a structure someone other than the original author can safely change.
Formstack Documents is a document generation product that merges structured data
into a template and delivers the finished file. Templates can be built in
Formstack's own drag-and-drop builder or supplied as Word, Fillable PDF, PowerPoint or
Excel files. Data-driven values are marked with merge fields in the form {$fieldName} — curly brackets with a dollar sign immediately after the opening
bracket. Output can be produced as PDF, DOCX, XLSX, HTML, XML and other formats, and
delivered by email, to cloud storage, into a CRM record, or onward for signature.
Implementing it is mostly a design exercise. How many templates should exist, what belongs in a conditional block rather than a separate file, how child records render as repeating tables, where the finished document lives and how long it is kept — those decisions determine whether a legal wording change later takes an afternoon or a fortnight.
Formstack Documents and Documents for Salesforce are not the same product. Formstack Documents runs on Formstack's platform, so Salesforce data travels out to be merged and the finished file comes back. Documents for Salesforce is a managed package that runs inside your org. The functional difference people notice first is attachment behaviour; the difference that matters to a security review is where the data was processed. The comparison table below sets out both.
The template format is chosen once and lived with for years. Choosing on the basis of what the design looks like today, rather than who will maintain it, is the most common source of regret in a document estate.
| Approach | Best for | Maintenance reality |
|---|---|---|
| Native drag-and-drop builder | Documents whose layout you control, where you want editing to stay inside Formstack. Supports output to PDF, DOCX, XLSX, HTML, XML and more. | Easiest for a non-technical owner to change safely. Layout control is good but not absolute. |
| Word (DOCX) template | Long-form documents — contracts, agreements, policy packs — where legal or another team already owns the wording in Word. | The document owner edits in a tool they already know. The risk is a merge field damaged by tracked changes or autocorrect. |
| Fillable PDF | Documents with a fixed, non-negotiable layout — regulator forms, statutory templates, anything where the design is prescribed. | Exact layout fidelity. The trade-off is that changes need a PDF editor and the field mapping is less forgiving. |
| PowerPoint (PPTX) | Generated decks: proposals, quarterly reviews, client reports. | Fine for slide-shaped output. Complex conditional logic is harder to express than in the other formats. |
| Excel (XLSX) | Structured tabular output: schedules, pricing tables, data extracts that someone will work with further. | Good where the recipient needs to manipulate the result rather than read it. |
Merge fields are the fragile part. Formstack's syntax requires the field to
open and close with curly brackets and to carry a dollar sign immediately after the opening
bracket — {$fieldName}. In Word templates, tracked changes, autocorrect and
formatting applied mid-token routinely break a merge field in ways that are invisible on
screen. This is exactly why we treat templates as controlled artefacts with a defined edit
procedure rather than as documents anyone can open and adjust.
| Consideration | Formstack Documents (cloud) | Documents for Salesforce (native) |
|---|---|---|
| Where the merge happens | On Formstack's platform. Salesforce data travels out and the finished file comes back. | Inside your Salesforce org, built off the Salesforce data model. |
| Data sources | Strong where several systems feed one document — useful when Salesforce is not the only source. | Salesforce primary and child objects, with SOQL available for more complex structures. |
| Attachment to the record | Delivery back to the originating record has to be configured deliberately. | Output can be attached to Salesforce records as part of the delivery options. |
| Triggering | From a form submission, an API call or a connected application. | From a button on any object, from Flow, or from a form submission. |
| Bulk generation | Handled through the platform's own processing and whatever orchestration you build around it. | Report-driven generation produces a document per row and can combine them into one file; high-volume generation uses Salesforce Batch Apex with a configurable batch size up to the platform maximum of 200 records. |
| Choose it when | The document draws on several systems, or the process is not Salesforce-centred. | Salesforce is the system of record and keeping the merge inside the org matters for security, attachment behaviour or volume. |
Package capabilities change between releases. Confirm the current behaviour for your installed package version before committing a design.
Forty templates that differ by a paragraph. A wording change means forty edits, thirty-nine of which get done. The difference should have been a conditional block driven by a field, not a separate file.
A template references a field name that means nothing to anyone currently employed. Changing it is unsafe because no one knows what populates it, so it stays — and the next person inherits the same problem.
A missing source value renders as empty space rather than as an error. The document goes out with a gap in a payment term or a party name, and nobody notices until a counterparty does.
The template was tested with a short company name and two line items. Production sends a long legal entity name and forty lines. Tables break across pages badly and the result is unusable — and unnoticed, because nobody tested at the extremes.
The document is generated and emailed. It is not on the record, not in the document management system, and not findable six months later when someone asks what was agreed. Generation without a delivery decision is half a process.
Generating one document works. Generating three thousand at month end is a different engineering problem — one that native Salesforce generation addresses with batch processing precisely because naive looping hits governor limits.
How many templates should exist, in which format, and what varies by condition rather than by file.
The field dictionary that makes a template legible to the next person who opens it.
What causes a document to exist, and what stops it being generated twice.
Where the finished file goes, who can reach it and how long it stays.
Designing for the month-end run, not just the single-record demo.
The controls that make a document estate defensible rather than merely functional.
Yes. Formstack Documents supports Word, Fillable PDF, PowerPoint and Excel templates alongside its own drag-and-drop builder, so most existing source documents have a direct path. What we recommend against is porting the whole library unchanged. A set of near-identical Word files usually collapses into a much smaller set of templates with conditional blocks, and doing that consolidation during migration is dramatically cheaper than doing it after the estate has been recreated.
Where the merge happens. Formstack Documents runs on Formstack's platform, so Salesforce data travels out to be merged and the finished file comes back — which is an advantage when a document draws on several systems and a consideration when your security review asks where personal data is processed. Documents for Salesforce is a managed package built off the Salesforce data model, so the merge happens inside your org, output can be attached to records as part of delivery, and high-volume runs can use Salesforce's Batch Apex framework. If Salesforce is your system of record, native is usually the better fit.
Yes, with the right design. Documents for Salesforce can generate from a Salesforce report — producing a document per row and optionally combining them into a single file — and offers a high-volume generation capability built on Salesforce's Batch Apex framework, with a configurable batch size up to the platform maximum of 200 records per batch. That framework exists because naive record-by-record looping hits governor limits. The engineering work in a large run is less about the generation itself than about what happens when record 1,847 fails: whether the run stops, continues, or is resumable.
Treat the template as a controlled artefact. Formstack's merge syntax requires each field to open and close with curly brackets and carry a dollar sign immediately after the opening bracket, and in Word that token is easy to damage invisibly — tracked changes, autocorrect and formatting applied part-way through a field name all break it while looking fine on screen. The controls that work are a documented edit procedure, editing with tracked changes off, a test generation before any template is republished, and a named approver for legally significant wording.
Yes. Delivery options include routing the generated document onward for eSignature, and pairing document generation with Formstack Sign is one of the more common reasons teams buy the two together. The design decisions that matter are who signs in what order, what happens when a signer does not respond, where the executed document and its audit trail are retained, and whether the signed version supersedes the generated one on the record. Those are process decisions rather than configuration ones, and they are worth settling before the build.
Most document estates have one template that everyone is quietly afraid of. It is usually the highest-volume one, and it is usually the one where the consolidation and mapping work pays back fastest.
Template architecture designed by the same team that designs the CRM data model behind it.