Merge Fields Within Service and Subservice Content

Service descriptions for services and subservices support dynamic merge fields. These work similarly to the merge fields used in document generation templates: wrap the field name in double curly braces to pull in project-specific data wherever the text appears.

Use merge fields in the Service Description field. Other language fields do not reliably substitute them.

How to Use Merge Fields

To include a merge field in a service description or subservice language field, wrap the field name in double curly braces. For example, to reference the quantity configured on the project, write:

{{quantity}}

You can embed merge fields naturally within a sentence. For example:

Install {{quantity}} routers at {{service_location_name}}.

When a document is generated, ScopeStack replaces each merge field with the actual project data for that service or subservice.

On this screen: The Service Language tab of the project services editor is open, with “Service Description” selected in the “Show / edit content for:” dropdown. A service row shows its name on the left and a rich text editor on the right containing example text like Install {{quantity}} routers at {{service_location_name}}. The double-curly-brace syntax is typed directly into the editor field and appears as plain text at this stage.

On this screen: A generated document shows the service description as it appears after document generation. The merge field placeholders have been replaced with actual project data — for example, {{quantity}} has been replaced with the numeric quantity configured on the project, and {{service_location_name}} has been replaced with the name of the service location assigned to that service.

Available Merge Fields

Three Things to Know Before You Use These

A misspelled or unsupported field name renders as nothing, not an error. {{Quantity}} (wrong case), {{service_location}} (missing _name), or any field not in the table above resolves silently to an empty string. Only the nine fields listed above are supported. If part of a sentence goes missing from a generated document, check the exact spelling against this table first.

quantity is a whole number with no automatic pluralization. It renders as a plain integer (1, 7, 12 — never 7.0). At a quantity of 1, the example above reads “Install 1 routers at …”. Word your content so it reads correctly at any quantity, for example “Routers to install: {{quantity}}”.

service_location_remote? renders the literal word true or false. It is a boolean, not a label, so dropping it into a sentence prints “true” or “false” in the text your client reads.

Referencing Survey Answers

Survey responses are not among the nine fields above, so a survey reference placed in a Service Description resolves to an empty string. Survey data is available at the document level instead, in one of two ways:

• To print a survey answer in the generated document, reference it in your template by the question’s response slug — for example {survey_responses.customer_size} on a Tag (V2) template, or <<= survey_responses.customer_size >> on a V1 Mail Merge template. See the V2 Merge Data Field Reference or the V1 Mail Merge reference.
• To have a survey answer drive a service, such as its quantity or whether the service is recommended at all, use survey recommendations and calculations rather than a text reference. See the Surveys overview.

To surface a survey-derived count inside a description (for example, the number of sites captured by a discovery question), route it through the service’s quantity: build a survey recommendation whose Quantity is the survey question or calculation, so the answer becomes that service’s quantity on the project, then use {{quantity}} in the description. This is the one supported way to surface a survey value inside service content, and it prints one value per service (that service’s own quantity).

When to Use Service-Level Merge Fields

Service-level merge fields are most useful when:

• You want service descriptions to reflect the specific quantity a client has scoped, rather than using static language
• You are building multi-site projects and need location-specific descriptions for each service
• You want to reference the client name or business unit inline within service content to reduce manual editing after scoping

For multi-site projects, service_location_name and service_location_address are particularly useful — they pull the location assigned to each individual service, so the same service template can produce distinct, location-accurate descriptions across all sites.