How to Build a .docx Template for Salesforce Document Generation

Summary

A document generation template for Salesforce is an ordinary Word document with merge fields written in double curly braces, for example {{Account.Name}}. At generation time each merge field is replaced with the value from the record, table rows repeat for child records, and the finished file is saved back to the record as a .docx or a PDF.

‍

This guide walks through building one end to end with DocGen by RavenApps: the SOQL query that feeds it, merge field syntax, repeating rows for line items, conditional sections, date and currency formatting for international documents, and the mistakes that cost people the most time.

‍

What is a .docx template in Salesforce document generation?

A .docx template is a normal Word document containing placeholder text that DocGen replaces with Salesforce data. There is no separate template format and no proprietary designer. The file you write in Word is the file that generates, which means anyone who can edit a Word document can maintain your templates, and the document you design is exactly the document your customer receives.

‍

What you need before you start

• Microsoft Word or Google Docs, since the template is just a .docx file
• DocGen installed in your org, or in a sandbox where it is free with full features and no time limit
• The object you are generating from, usually Opportunity, Quote, Account or a custom object
• A list of the fields you want on the document, including fields on related records

‍

No proprietary designer, no separate template builder, and no training beyond knowing how to use Word.

‍

Step 1: Write the SOQL query

The query defines what data is available to the template. Anything not in the query cannot be merged, so this is the step that determines everything downstream.

‍

A typical order form query pulls fields from the Opportunity, fields from its parent Account, and a nested subquery for the line items:

‍

SELECT CurrencyIsoCode, Amount, Account.Name, Account.Phone,
Account.BillingAddress,
(SELECT CurrencyIsoCode, Product2.Name, Quantity, TotalPrice FROM OpportunityLineItems)
FROM Opportunity

‍

Two things to note. Parent fields are reached with dot notation, so Account.Name works without a separate query. Child records come from a nested subquery, and the relationship name in that subquery, OpportunityLineItems, is what you will reference when you build repeating rows.

‍

Step 2: Add merge fields to your Word document

Open your document and type merge fields wherever a value should appear. The syntax is the field name from your query, wrapped in double curly braces:

‍

• {{Account.Name}} for the customer name
• {{Account.BillingAddress}} for the full billing address
• {{Account.Phone}} for the phone number
• {{Account.Primary_Contact__r.Name}} for a field on a related custom lookup, using the __r relationship suffix
• {{Term2__c}} or {{StartDateFmt__c}} for custom fields on the record itself

‍

Formatting is inherited from the document, so a merge field styled bold in Word produces bold text in the output. Build the template to look exactly like the finished document, because that is what it will be.

‍

Step 3: Repeat rows for line items

This is the part people expect to be hard. It is not. To repeat a table row for every child record, wrap the row between a START and an END tag naming the relationship:

‍

• In the first cell of the row that should repeat, add {{START:OpportunityLineItems}}
• Add the child field merge fields across that row, for example {{OpportunityLineItems.Product2.Name}}, {{OpportunityLineItems.Quantity}}, and {{OpportunityLineItems.PUPM__c}}
• In the row below, add {{END:OpportunityLineItems}}

‍

At generation, the tagged row is duplicated once per child record and the tags disappear. An opportunity with seven products produces seven rows, and the subtotal, tax and total rows underneath stay exactly where you put them.

‍

Step 4: Conditional content

Conditional content shows or hides sections of the document based on record data. It is how one template serves several scenarios instead of maintaining a separate file for each.

‍

Typical uses: a discount clause that only appears when a discount was applied, a purchase order reference that only prints when the customer supplied one, a jurisdiction-specific legal paragraph, or a payment terms block that varies with contract length. One order form template can then cover every combination, which matters because every extra template is another file someone has to remember to update when wording changes.

‍

Step 5: Dates, currencies and international documents

Output formatting is per your locale, so dates, currencies and numbers come out in the convention your reader expects rather than the convention the database stores.

‍

For documents going overseas, dates can be rendered in the local language. The function takes a format pattern and a language code, so {{TODAY("d MMMM yyyy", "fr")}} produces 4 août 2026 rather than the English equivalent. Addresses are formatted per country, which sounds like a small thing until you have sent a contract to a German customer with the postcode in the wrong position.

‍

File names can be dynamic too, built from record fields, so generated documents arrive named after the account and date rather than as a series of identical filenames in Salesforce Files.

‍

Step 6: Upload the template and generate

1. Save your finished document as a .docx file.
2. Upload it through DocGen Manager, which handles template upload, versioning and management in one place, built on standard Salesforce Files.
3. Add the DocGen Button component to the relevant Lightning page, which can be a record page, the Home page, or an App page.
4. Configure the button with the template and the SOQL query.
5. Click it on a real record. The document is generated, saved to the record, and opened.

‍

Because templates live in standard Files, they deploy cleanly between orgs and survive sandbox refreshes, and new versions upload with full history rather than overwriting what came before.

‍

Can one .docx template produce both Word and PDF?

Yes. The same .docx template generates either format, so you are not maintaining two versions of the same document. Use PDF for anything final that should not be altered, such as a signed order form or an invoice, and .docx when the recipient needs to edit, for example a colleague adjusting terms before sending.

‍

Common template mistakes

• Merging a field that is not in the query: the single most common cause of a blank value. If it is not selected, it cannot merge.
• Word splitting a merge field: if you edit inside a merge field, Word sometimes breaks it across formatting runs and it stops matching. Retyping the field cleanly usually fixes it.
• Forgetting the END tag: a START without its matching END will not repeat rows correctly.
• Not testing against a record with missing data: templates that look perfect on a complete record can leave awkward gaps or stray labels on a sparse one. Always test the empty case.
• Building separate templates instead of using conditions: three near-identical templates become three things to maintain. Use conditional content.

‍

Useful Links

• DocGen AgentExchange Listing
• DocGen: Native PDF Generation Update
• 7 Questions to Ask Before Choosing a DocGen App
• Book a Call
• Website

‍

Thank You

Thanks for reading. If you have a document you want to turn into a template and would rather not start from scratch, send it over and we will walk through it with you. Book a Call or Contact Us.