What is a Language Field?

Language Fields give you space to define content about a service or service beyond simply describing the work that will be done, such as defining assumptions related to the completion of the service or deliverables resulting from the work performed.

In a project, you may need to note things like:

• Clarifying actions related to the service that will not be performed (Out of Scope or Exclusions).
• Responsibilities the customer will have as a result of a service’s inclusion in a project (Client Responsibilities).
• Assumptions include specifying the time of day a service may be performed (Assumptions).
• Deliverables that will be produced as a result of the services’ inclusion in the project (Deliverables).

Language Fields allow you to accurately define and document this information for specific services and subservices, providing enhanced precision and control when describing your work within projects.

Setting up Language Fields

Viewing the List of Language Fields

Language Fields can be set up and edited under Settings > Content > Language Fields. Here, you will find a list of Language Fields in your account.

On this screen: The Language Fields page has Active and Archived tabs and columns for Name and Service Description, in that order. Despite the header, Service Description holds the field’s code, a lowercase, underscored identifier such as assumptions or out used by document templates. Rows on the Active tab can be dragged to reorder them. + Add A Language Field appears in the header. Select rows to use bulk Delete on the Active tab or Restore on the Archived tab.

• You can edit a Language Field by clicking on any item.
• You can re-sequence the order your language fields will be displayed in by grabbing the “handle” on the left side of the language field list, and you can remove fields by selecting their checkboxes and clicking Delete.

On this screen: On the Active tab, drag handles on the left let you reorder language fields. Row order controls their display sequence throughout the platform. Select rows using their checkboxes to reveal bulk Delete.

• To create a new Language Field, click + Add A Language Field.

The field code

Every language field has a code as well as a name. The name is the label you see throughout the platform. The code is what document templates refer to, and it is the value shown in the second column of the list above.

The code is generated from the name the first time the field is saved, and only then. Renaming a field afterwards never changes its code. That is deliberate: relabeling a field cannot break a template that already works.

Name and code therefore diverge, and on an established account they can end up looking nothing alike. The fields a new account starts with are already shorter in code form than in name:

Renames widen the gap from there. A field created as “Customer Select” and later renamed to “Client Select” still answers to customer_select, and a field renamed from “Deliverables” to “Deliverables/Success Milestones” still answers to deliverables.

So when you are building or debugging a template, work from the code, not from the label. A field that has been renamed will not tell you its code from its name, and a guessed code produces a tag that silently returns nothing.

Deleting a language field

Removing a field archives it. To restore it, open the Archived tab, select the field, and click Restore. Archiving removes it from the Active list, from the Show / edit content for dropdown on services and projects, and from the merge data your templates read. Any template tag still pointing at it stops returning anything.

The content you authored is not erased. It remains stored against each service under the field’s code. Deleting the field puts that content out of reach rather than destroying it.

Restore it from the Archived tab. That is the only route, and it is the one that keeps the field’s original code and reconnects everything previously written on your services.

⚠️ Do not try to bring a field back by re-creating it with the same name. An archived field still holds its name and its code, so creating a new one with that name is rejected with “Name has already been taken”. On the older settings screens re-creating by name did quietly restore the original; on the current screens it does not.

If you cannot find the field on the Archived tab, contact support rather than guessing.

Creating and Modifying Language Fields

When you click on an existing field or opt to create a new one, you will see the following options.

On this screen: The Add a Language Field or Edit Language Field form contains Name, Introduction, and Conclusion. Introduction and Conclusion are Markdown editors with placeholders “Text to be added to the document before all values” and “Text to be added to the document after all values”. Existing fields also show their code as read-only text under Service Description. Save and Cancel appear in the header, with Save and Add Another when creating a field.

On new Language Fields, you can set up their:

• Name: This is the name that will be shown in user interface items on the platform.
• Introduction & Conclusion: These give you a place to specify opening and closing language for the language field that can be included in document templates. For example, at the beginning of your list of Deliverables, you may want to have a heading that is the name of the field (“Deliverables”) and then a sentence that explains the text (“The following deliverables will be created as a result of the work outlined in this statement of work”). The Introduction field gives you a place to specify this text that’s then available in the merge data for you to use to build your document templates. Note that these fields are not editable on a project-by-project basis.

On Services in Settings

In Settings, when you are in Professional Services or Managed Services, you can access Language Fields under the Service Language tab on your service.

On this screen: The service edit page showing a tab bar with five tabs: General, Service Language, Products, Assign Teams & Tags, and Version History. The Service Language tab is selected, and a Save button appears in the top-right header alongside a Back (or Cancel) button.

When you first land on the Service Language tab, you will be shown the Service Description information. You can use these fields to describe the work being performed during each service or subservice. To access the Language Fields, you can use the Show/Edit Content For selection to select the language field you would like to view or modify.

On this screen: The Service Language tab content. At the top, a Guidance Language textarea (3 rows) with placeholder “Enter guidance language for the service.” Below that, a row labeled Show / edit content for: with a 300px-wide single-select dropdown defaulting to “Service Description.” The dropdown options include “Service Description” plus any language fields configured for the account. Below the selector, a table with columns Service Name (read-only text input) and Service Description (markdown textarea with a tooltip info icon in the column header). Subservice rows appear nested beneath the parent service row.

Once you select a Language Field, you will see the existing language for that language field on the service you are editing.

On this screen: The same Service Language tab, now with a specific language field (e.g. “Assumptions”) selected in the Show / edit content for: dropdown. The table column header updates to show the selected field name (e.g. “ASSUMPTIONS”) with an info icon tooltip. Each service and subservice row shows the current content for that language field in its markdown textarea, which is editable.

You can then begin making edits. If you attempt to change tabs before saving your content, you will be prompted to save before leaving the tab.

On this screen: An unsaved changes confirmation modal has appeared, asking whether you want to save your changes, discard them, or cancel the tab switch. The modal presents three buttons: Cancel (stays on the current tab), Don’t Save (discards changes and navigates away), and Save (saves and then navigates).

On Services in a Project

Using pre-defined services

After you’ve added a pre-defined service to a project, it will pull in any language present on the Settings version of that service. You can then modify it on a per-project basis without affecting the settings version of a service.

To access a Language Field in a project, click the appropriate option from the Professional Services section.

On this screen: The Professional Services section of a project, showing a tab bar with Services, Service Language, and (if enabled) Service Pricing tabs. The Service Language tab is selected. At the top of the tab content, a Show / edit content for: label is followed by a single-select dropdown currently showing “Service Description.” Below it is a table listing each service and subservice, with columns SERVICE NAME (read-only) and SERVICE DESCRIPTION (markdown textarea with an info icon in the header).

Once you select a Language field, you will see the language displayed.

On this screen: The Service Language tab with a specific language field selected from the Show / edit content for: dropdown (e.g. “Deliverables”). The table updates: the second column header now reads “DELIVERABLES” (matching the selected field name). Each service row shows the current language field content for that service in an editable markdown textarea. The service name column remains read-only.

If you have the necessary permissions, you can modify the language fields for each project by clicking the Save button at the bottom of the page once you have finished making changes. If any adjustments are made to a language field, it will be highlighted in red to signify that it differs from the standard version. You can click the Show Changes button to compare the language used in the project against the original language field in the service settings.

On this screen: A service language editing view showing a markdown textarea for the currently selected language field. A Show Changes button (outlined secondary style) appears in the top-right area. When the project’s language for this field differs from the standard settings version, the textarea border or field indicator is highlighted in red to signal the divergence. Clicking Show Changes opens a side-by-side diff view comparing the project version (left) against the original service settings version (right).

Using Custom Services

If you’ve created Custom Services on a project, you can follow the same method outlined above to access the Language Fields for your project and define the language appropriately.

Using Language Fields in Documents

Two different fields can share a name. Out of Scope and Client Responsibilities also exist as project-level fields on the Customer Summary section of the project, separate from the language fields authored on each service. A template refers to one or the other. If a section comes out empty or missing entirely, check which one your template uses before re-entering the content: a conditional section whose field is empty prints nothing at all, heading included. Key Assumptions, Deliverables, and Success Criteria have no project-level equivalent and are always per service.

The same split shows up in Mail Merge (V1) merge data, where the names differ only by a suffix: out_of_scope is the project-level field, while out_of_scope_with_components is the content authored on your services.

In a tag (V2) template, the project-level fields are project.out_of_scope and project.customer_responsibilities, and the content from your services is the language_fields entry with the slug out or customer. There is no project.formatted_assumptions or project.formatted_deliverables: Key Assumptions and Deliverables are only in language_fields.

The _with_components field is named from the field’s name, not its code. This is the one place the name matters. out_of_scope_with_components is built by lowercasing the field’s name and replacing spaces with underscores, while the per-service tags for the same field (task.formatted_out) use the code. So renaming a language field renames its _with_components field along with it, and a template still using the old name goes quiet: no error, just an empty section. The per-service tags carry on working, which makes it look as though only part of the field broke.

For the same reason, keep punctuation out of language field names. A field named “Deliverables/Success Milestones” produces deliverables/success_milestones_with_components, which is not a usable merge field name.

In a tag template, a language field renders a heading followed by its content. To render that content with the formatting authored in the field (bold, links, and nested bullet lists), use the rich-text tag over the field’s HTML variable, {~~formatted_sentences}. The plain {#sentences}{.}{/sentences} loop inserts each raw line as plain text instead — it escapes any HTML and flattens a nested list to one bullet per line — so reserve it for deliberately unformatted output.

Whether the roll-up looks like a list is decided on the services, not in the template. Each service that contributes to a field supplies one entry, and the entries are joined with a single line break. Markdown treats a single line break as a space, so four services that each contributed a plain sentence render as one run-on paragraph rather than four lines. Author each one as a list item, using the bullet button in the editor or a - typed in front of the text, and the roll-up becomes a real list with one bullet per contributing service. No template change is needed for this: the same {~~formatted_sentences} tag renders a paragraph or a list depending on what the services hold.

Identical entries are collapsed. If two services carry exactly the same text in a field, it appears once in the roll-up. Four services with three distinct deliverables produce three bullets, and nothing in the document indicates that a duplicate was removed. Vary the wording if both occurrences should appear.

Because the content is rolled up from the services and subservices, a field can end up with a heading but no content on projects where no service contributed to it. To keep an empty heading (for example, “Deliverables”) from printing, wrap the heading and its content together in a {#sentences.length > 0} guard:

{#language_fields}
{#slug=="deliverables"}
{#sentences.length > 0}
Deliverables
{~~formatted_sentences}
{/sentences.length > 0}
{/slug=="deliverables"}
{/language_fields}

Keep the {#language_fields} and {/language_fields} lines. slug and sentences only exist inside that loop, so the inner block on its own prints nothing.

When the field has no content, the whole block is skipped and nothing prints. See Hiding a heading when its section is empty for the full pattern and a fallback-text variant.

Be sure to check out our Common Merge Field templates for examples of how to use them in projects, and learn how to read and use the Merge Data to create your own varieties.

Permissions

The Language Fields (settings.language_fields) permission under Settings > Roles controls access:

• View: See language fields configured in Settings and view their content on services.
• Manage: Create, edit, and delete language fields in Settings, and modify language field content on services and projects.