V1 Mail Merge Templates (Legacy Reference)

This article covers the legacy V1 Mail Merge format. If you are building new templates or migrating existing ones, use Tag Templates instead. Tag Templates are faster, support more file types, and use an industry-standard tag syntax. See What Are Tag Templates? to get started, or email support@scopestack.io for migration help.

Starter Templates

The templates below use the V1 Mail Merge format. They continue to work for accounts already using them and are provided here as a reference.

Download starter templates from Google Drive  — open with Microsoft Word.

The same folder also includes a generic Tag Template (V2) starter for the current template format, in case you are not building in the legacy Mail Merge format.

Professional Services-Only Template

The standard single-phase task document. Key features:

• Follows the task ordering set in the Scope Editor.
• Applies unique language filtering — only unique language per phase is listed for Language Fields.

Required language fields:

• out — Out of Scope
• customer — Client or Customer Responsibilities
• assumptions — Assumptions
• deliverables — Deliverables

Managed Services-Only Template

The standard managed-services document. Key features:

• Follows the task ordering set in the Scope Editor.
• Applies unique language filtering.

Requires the out (Out of Scope) language field.

PS + MS Template

Displays both Professional Services and Managed Services in a single document. Key features:

• Follows the task ordering set in the Scope Editor.
• Applies unique language filtering.

Required language fields:

• out — Out of Scope
• customer — Client or Customer Responsibilities
• assumptions — Assumptions
• deliverables — Deliverables

Field Syntax

V1 templates use Word Mail Merge fields. To insert a merge field in Word, go to Insert > Field, select Mail Merge from the Categories list, then choose MergeField from the Field Name list.

Key-Pair Value Fields

A key-pair field inserts a single value into the document at the location of the field. The field name always starts with an equals sign:

<<= price >>
<<= project_name >>
<<= client_name >>

The value that is inserted inherits the formatting of the field placeholder in your template.

Flow-Control Fields

Flow-control fields direct the merge process to loop over arrays or conditionally include content. They always come in pairs: an opening field that starts the block and a closing field that ends it.

Conditional (if/endIf):

<<= price:if(present) >>
  This project is priced at <<= price >>.
<<= price:endIf >>

The merge process adds the text between the if(present) and endIf fields only when the value exists. You can include additional merge fields inside the block.

Each loop:

<<= phases_with_tasks:each(phase) >>
  Phase: <<= phase.phase >>
<<= phases_with_tasks:endEach >>

The each block iterates over an array. The name in parentheses — phase in the example above — becomes a temporary variable you can use to access fields on each item. You can nest conditionals inside each loops, and each loops inside conditionals.

Common V1 data objects:

• phases_with_tasks — Professional Services phases. Services are referred to as “tasks” in this object; subservices are “features.”

• managed_services — Managed Services

• project_pricing — Pricing elements, including nested arrays. Dot notation accesses nested values: project_pricing.professional_services.revenue.

  Inside the project_pricing.resources loop, quantity is that resource’s total rounded hours, not a unit count. It is a per-resource rollup across the whole project, so «=pricing.quantity» is the value you would label “Effort (hrs)”, never a service’s quantity. Do not use it to print how many of something a project includes. To show a service’s own quantity, use a merge field inside the Service Description instead — see Merge Fields Within Service and Subservice Content.

• language_fields — Language fields available on the project, structured similarly to phases_with_tasks.

• third_party_services — Contains partner_services (from Partner Requests) and vendor_quotes (ad hoc additions). Each has a vendor description and an “Our Description” value.

• locations — Project locations with assigned services.

• lines_of_business — Professional Services organized by Line of Business at the top level.

• survey_responses — Questionnaire response values, keyed by response slug. Use dot notation to reference a specific answer as a key-pair field: <<= survey_responses.customer_size >>. Each value is the response text or the selected option’s value; date responses are formatted per your account settings. This is document-level survey data and is not available as a merge field inside Service Descriptions — see Merge Fields Within Service and Subservice Content.

Text Blocks

Text blocks are reusable content blocks created in Settings > Documents > Text Blocks. They can include merge variables using a modified syntax.

In a document template, the key-pair field =fieldname inserts a value. In a text block, the same variable uses double-curly-brace syntax:

{{client_name}}

This lets you dynamically insert project data — such as the client name — into text block content, which is then merged into the final document. The same pattern works for any key-pair merge variable.

Text blocks cannot use Service Descriptions, Language Fields, or Customer Summary blocks.

To insert a text block by its Merge ID, use the key-pair field:

<<= signature_block >>

where signature_block is the Merge ID defined in your text block settings.

Markdown Formatting

Markdown is supported in the following areas of the platform:

• Text Blocks
• Terms and Conditions
• Service Descriptions and Subservice Descriptions
• Language Fields
• Executive Summary, Solution Summary, Our Responsibilities, Client Responsibilities, and Out of Scope

Fields outside this list are plain text and do not render markdown. In particular, Expense and Product Description fields print exactly as typed — markdown such as **bold** or a | a | b | table comes through as literal characters. To bold a label in a travel/expense or product table, apply the formatting in the Word template itself rather than typing markdown into the data field.

How markdown content is styled (read this before setting fonts)

Markdown-formatted content is not inserted into the merge field’s own run. The generator converts your markdown to new Word paragraphs and replaces the paragraph the merge field sits in.

Those generated paragraphs carry no font of their own. They take all of their formatting from paragraph styles referenced by name:

Paragraph is not a built-in Word style. Word does not ship one, so most templates do not have it — and when the style a paragraph references does not exist, Word applies no paragraph style at all and the text falls back to your document’s default font (usually the theme font, such as Calibri).

This is why a brand font can appear correctly on static text and on ordinary merge fields, but not on service descriptions, summaries, or other markdown-formatted content.

Style IDs, not the names you see in Word

The generator references a style by its style ID, which has no spaces in it. Word’s Styles Pane shows you the style’s display name, which usually does. They are not the same string:

Every style in that table except Paragraph already exists in Word, and already carries the ID the generator looks for. So for those, modify the built-in style that is already there. Do not create a new one.

This matters more than it sounds. If you create a second style and name it “List Bullet” while Word’s built-in List Bullet already exists, Word will not let the IDs collide: it quietly gives your new style a different ID, such as ListBullet0. The generator never references that ID, so your font change applies to nothing and the document comes out unchanged. The style looks correct in the Styles Pane, which is what makes this one hard to spot.

To control the font of markdown-formatted content:

1. Create a paragraph style named Paragraph and set your font on it. This is the style that governs all markdown body text, and the one virtually every template is missing. It is the only style in the table above you have to create yourself.
2. Set the same font on Normal, ListBullet, and ListNumber. If your template already has one of these, modify it in place. Never add a second style alongside one that is already there.
3. Build the list styles from a real list. If ListBullet or ListNumber is missing, add it by formatting an actual bulleted or numbered list and styling that, rather than styling a blank paragraph. A list style that is not attached to Word’s numbering definitions fails document generation outright (see below).
4. Put the merge field in its own paragraph. Markdown rendering replaces the entire paragraph containing the field, so any other text sharing that paragraph is removed from the document.

You can create and edit styles via the Styles Pane in Word. See Microsoft’s documentation on adding styles  for details.

Fonts are referenced by name, not embedded. If you use a font that is not installed on a reader’s machine (for example, a macOS-only font opened on Windows), Word silently substitutes a different one. No template change can prevent this — the font must be installed wherever the document is opened.

Supported Markup

• Paragraph text, bold, and italic.
• Headings. # through ###### map to the Heading1 through Heading6 styles.
• Bulleted lists. Requires a ListBullet style in your Word document.
• Numbered lists. Requires a ListNumber style in your Word document.
• Nested lists. Indent sub-items three spaces under their parent. Two spaces nests a bulleted list but will not nest a numbered list, so use three for both.
• Links. [text](https://example.com) renders as a real Word hyperlink, styled with the Hyperlink character style.
• Tables. A markdown pipe table renders as a real Word table. Cell text uses the Paragraph style, the same as body text.
• Inline code. Single backticks around a word render as ordinary text with the backticks stripped. You get plain text, not a monospace font. (Fenced code blocks are a different thing, and they fail the document. See below.)

Some markdown will fail document generation entirely. The following are not supported by the V1 generator, and they cause the document to fail rather than render incorrectly:

• Blockquotes. Any line beginning with >.
• Strikethrough. ~~text~~.
• Task lists. - [ ] item.
• Code blocks. Text fenced with triple backticks, or any line indented four or more spaces.
• Images.
• Angle-bracket text that reads as an HTML tag. <hostname>, <server>, <your-domain>, and literal HTML such as <b>bold</b>.

The last two catch people out, because neither looks like markup. A line indented four spaces becomes a code block even if you only meant to indent it, and text like reboot <server> nightly is read as an HTML tag. Use plain text, a heading, or a blank line instead. For a placeholder, drop the brackets and write reboot SERVER nightly.

Horizontal rules (---, ***, ___) do not fail, but they are silently removed from the generated document — and a --- typed directly beneath a line of text turns that line into a Heading 2. Don’t use them.

A ListBullet or ListNumber style that is not connected to a Word list (numbering) definition will also fail generation. Create the style by formatting a real bulleted or numbered list, rather than from a blank paragraph.

Only the markup listed above is supported. A general Markdown reference will show you syntax that this generator cannot render, including code fences, images, blockquotes, and task lists.

Inserting Markdown-Formatted Fields

Fields that support markdown have two versions in the merge data: a raw key and a formatted_ key. Reference the formatted_ version to render real bold, italics, and lists; the raw key prints the markdown characters as typed.

Terms and Conditions:

«terms_and_conditions:each(term)»
  «=term.formatted_content»
«terms_and_conditions:endEach»

Loop over terms_and_conditions and insert each term’s formatted_content. Note that formatted_content is a single value, not a list — do not loop over it directly.

Service and subservice descriptions:

«phases_with_tasks:each(phase)»
  «phase.tasks:each(task)»
    «=task.name»
    «=task.formatted_sentences»

    «task.features:each(subtask)»
      «=subtask.name»
      «=subtask.formatted_sentences»
    «task.features:endEach»
  «phase.tasks:endEach»
«phases_with_tasks:endEach»

Note that the subservice collection is named features, not subservices.

formatted_sentences replaces a «task.sentences:each(sentence)» loop — it does not accompany one. It is the same content, rendered. If you add it while keeping the sentences loop, every description prints twice: once formatted, and once as raw markdown characters.

Prefer formatted_sentences over formatted_service_description. The two look interchangeable, but formatted_service_description does not substitute merge fields typed inside service content — a {{quantity}} in a description would print literally.

The formatting applied to the merge field placeholder itself has no bearing on output.

Paragraph breaks. Within a markdown-formatted field, a single line break renders as a line break inside the same paragraph. To create a genuine new paragraph — with the spacing your Paragraph style defines — leave a blank line between blocks of text.

Products (Materials)

Products are accessible in V1 templates through the materials object. The correct loop structure is:

«materials.items:each(item)»
  «item.name» - Qty: «item.quantity» - Price: «item.ext_price»
«materials.items:endEach»

materials.items is the array of product line items. Each item exposes name, quantity, unit_price, ext_price, and other product fields.

Common mistake: Looping over materials.categories expecting nested items does not work:

«materials:each(mat)»
  «mat.categories:each(cat)»
    «cat.items:each(item)»...«cat.items:endEach»
  «mat.categories:endEach»
«materials:endEach»

materials.categories is a flat string array of category names, not an array of objects with their own items arrays. Iterating it with each will not give you product rows. Use materials.items:each(item) to access the actual product list.

Travel & Expenses

Travel and expense items are accessible in V1 templates through the top-level travel_and_expense array. Loop over it to build a travel/expense table:

<<= travel_and_expense:each(expense) >>
  <<= expense.description >> - Qty: <<= expense.quantity >> - <<= expense.total >>
<<= travel_and_expense:endEach >>

Each expense exposes resource, expense, description, quantity, rate, and total (rate and total arrive pre-formatted as currency).

• expense.expense renders as “Category: Description” — the expense category name joined to the line description. If every item sits in one category, that prefix repeats on every row.
• expense.description is just the line item you entered. Pair it with expense.quantity for a clean per-row label and count.

An expense appears in the document only if it has a Resource assigned and a quantity other than zero. The travel_and_expense list is built from expenses that have a resource set and a non-zero quantity, so an item with no Resource (or a quantity of zero) is silently skipped. It still shows on the project’s Travel/Expense screen, but the loop has nothing to render — which is the usual reason a travel/expense-only document comes out blank. If your table renders empty, confirm each expense has a Resource assigned.

The service an expense is linked to (“Which Service Makes Use of This Expense?”) is not available as a merge field. If you need the service name in the document, include it in the expense Description.

Row order follows the underlying data (sorted by resource name, then expense category) and is not user-sortable in V1.

Common Fields Reference

A comprehensive list of common V1 merge fields is maintained as a downloadable Word document.

View the Common Merge Fields document  — download from Google Drive and open with Microsoft Word.

This reference covers frequently used key-pair fields and flow-control patterns for projects, phases, tasks, pricing, and language fields. Fields can be copied directly from the document into your templates.

For V2 (Tag Template) fields, see the V2 Field Reference instead.