Creating a template

When dealing with the requirement from a company to build a template, iterate through the following processes.

Design

Implement

Test

Common properties

Template name

Name of the template as it appears in lists of templates. This is required.

Language

Spoken language of the template. See Language property and translations, below, for information about this property.

Template priority

Determines the order in which the templates are evaluated when Experience Cloud searches for a template to use. Lower numbers appear at the top of the list, and are processed first.

Templates of the same type (survey, alert, Rapid Response, and user) are treated as a group, and the Template priority property determines the evaluation order within each group. Templates assigned to a unit do not use priority, since those templates are available only to that unit.

For survey messages, priorities aren't used when the template is assigned directly by the Inviter or when the template is selected by Unit Group.

Note: All templates must have a condition to have a priority.

Content type

Format of the message content, either:

• Plain text — No styling or formatting, just text. This option activates the Plain text body editor with the Plain-text properties.

• HTML only — Uses HTML formatting and styling. This option activates the HTML body editor with the HTML properties.

• Plain text and HTML — Message contains both formats. This option activates both editors, and sends both formats in the message. The content application then determines which format to display.

Plain text is the most portable format and should be viewable by any content application. However, most modern email applications can render both formats.

Condition

Tells Experience Cloud when to chose this template when one is not specifically named in the Distributions, Actions, or Rapid Response emails specifications.

Important: This property does not apply to User account notifications.

When the specification does not include a named template, Experience Cloud picks a one by testing each template, starting with the lowest Priority, in the following order:

1. Templates with a matching Condition expression.

2. When no Condition is present, the group selected in the Scope property.

The condition expression is often a test to see if the Unit in the survey record is associated with a specific Unit group, or if the recipient belongs to a special class or group. 

Tip: To keep a template from being selected, set the Condition value to false. Similarly, to create a default template, assign a high Template priority and a Condition of true.

See Conditional expressions for detail about how to specify a condition.

In the following example, the invitation type is an E-field whose a value provided by the company. This condition is true when the value of that field is 2 or 3: e_example_invitationtype_alt in {2,3}.

Scope

Specifies when to use the template for a survey invitation or reminder, when an Email inviter is set to Based on EmailTemplate UnitGroup/ Condition. Otherwise, this scope has no meaning.

See Condition, above, for details.

Warning: This feature is deprecated and will be removed in the future. Minimal support is available.

Email subject

Text of the email subject field. The Email subject line allows for conditioning, which should follow the format $if field$text$endif$. This is displayed only if the field value is non-null.

Available tags

Tags are placeholders for information from Experience Cloud or from the survey record to include in the message. The value of the tags is determined when the message is rendered. The list of available tags begins with ones appropriate for the type of template, such as Alert-specific tags for Alert notifications, and User-specific tags for messages to Users. The rest of the list is all the A-fields in Experience Cloud.

Plain-text properties

Plain text body

Message to use for plain-text template. The text can include Tags to insert values when the message is rendered.

HTML properties

HTML body

Content and source for HTML format messages. Like plain text, the content can include Tags to insert values when the message is rendered. Any valid HTML code can be included. Additionally, the message can include any of the images defined in Survey designs as shown below.

For a collection of templates for various scenarios and formats, see HTML templates.

Customization

A design variation that includes images to be made available for inclusion in the template.

Available images

Images defined in the Variation, and which may be included in the template. See HTML image references, below, for details.

HTML format

HTML messages can include simple formatting, like this:

Or more complex, like this message that uses a table to organize the elements, and includes text styling directives:

If the styling you apply includes setting a font, Medallia strongly recommends using cross-platform-safe fonts, that are guaranteed to be available natively and supported by most email clients.

HTML image references

Include images by referencing them with standard HTML elements. You can reference an image from your company's web server, or use an image associated with the company's brand. Survey designs defines the images available as part of a variation.

For example, to reference the email header logo, use the $img_Email_Header_logo$ tag:

<td><img border="0" alt="Acme Co" src="$img_Email_Header_logo$"/></td>

Preview and test

The Preview and test feature shows a general sample of how the template looks when rendered, including content from a survey record. When viewing the sample you can:

• Change the survey record used to populate the tags by either entering specific ID in the upper right, or clicking the refresh button next to the ID field. 

• Send the preview to an email address.

Language property and translations

The message in a template may be any language, as identified by the Language property of the template. Additionally, a template may be translated into one or more additional languages using the Translations. These two features are not directly related.

The Language property is used when the company has preferred languages. The invitation module compiles an ordered list of preferred languages for the recipient or unit, and then uses that list when evaluating the Language property, with preference given to the first languages in the ordered list. When no templates have a Language in the list, then just the Condition and Scope properties determine the template to use.

Once a template has been identified, and when there is a list of preferred languages, Experience Cloud picks a translation corresponding to the first language it finds in the ordered list. If none are found, Experience Cloud uses the original template. When multiple translations match multiple languages in the list, Experience Cloud uses the Multi-language template to wrap each of those translations into a single message. See Multi-language templates below for details.

In summary, the template and translations are selected as follows:

1. Select a language.

2. Collect the ordered list of preferred languages, if any.

3. Select a template, attempt to use the Language if there is a preferred list.

4. If there is a language list, attempt to pick a translation of the template that matches a language in the list.

5. When multiple translations match languages in the list, use a Multi-language template to wrap the translations into one message.

Multi-language templates

Experience Cloud uses the Multi-language template to wrap each of those translations into a single message after the invitation module selects an email template and when:

Depending on the content type, the recipients can:

• For HTML content, recipients may select the language translation to use. 
• For plain-text content, the translations appear one after the other in the message: the recipient scrolls to read the translations.

Setting multi-language templates

To use multi-language templates:

1. Define a template for the default target language:
   1. The Content Type must be either HTML only or Plain text and html.
   2. The HTML Body must include this anchor near the top of the content: <a name="$LANGUAGE.id$"></a>
2. Define one or more translations for the template. See Localization for details:
   1. Each translation must have an HTML Body that includes this anchor: <a name="$LANGUAGE.id$"></a>. Note that you should not update the markup itself of the translation strings.
3. Define a multi-language template wrapper:
   1. The Content Type must be either HTML only or Plain text and HTML.
   2. The HTML Body and optional Plain Text Body properties must include variables to insert the translated messages.

When the message is rendered, Experience Cloud combines each of the templates and translations into one message. For HTML content, each template and each translation include the <a name="$LANGUAGE.id$"></a> tag, which each become HTML anchor links in the final HTML message. The anchor name value is the ID of the language.

The multi-language template is a wrapper that tells Experience Cloud how to format the combined output. It should follow this best practice format:

$if(HAS_MULTIPLE_LANGUAGES)$
<center>
Choose your language: $LANGUAGES:{<a href="#$it.id$">$it.name$</a>}; separator=" | "$
<br/><br/>
<center>
$endif$
$HTML_BODIES; separator="<hr/>"$

In the template:

• $HTML_BODIES$ — Inserts the contents of a <body> portion of the template and translations. The separator attribute is text to place between each translation. In the example above, the text uses an <hr/> HTML tag. Any valid HTML can be specified.

• $LANGUAGE$ — Inserts links to the individual translated messages. For each message and translation, insert the language ID in the href, and the language name in the text of the link.

This illustration demonstrates how it all works. This example has an template in English, and it has two translations: French and Swedish.

When the Experience Cloud renders the message, it creates a single HTML message using the Multi-language template as a wrapper. It then inserts the rendered template, and then each of the translations, in the order defined by the preferred languages list.

Plain-text output is similar, except there are no anchors and links.

Notes

• For languages that are written from right to left, include direction tags in the HTML code. The HTML templates screen includes examples in the template comments. 
• When a translated choice set is piped into the template, template uses the In report property value of the translation, not the In survey version of the translation. When sending emails in a language not being used for report translations, you need to temporarily:

  1. Turn on Reporting translations for that locale.

  2. Populate the In Report value of the choice set.

  3. Turn off reporting translations for that locale.

• If you make changes to an template code after carrying out a translation, keep in mind that the translations must be updated too, even those in the same language as the original text. For example, if the original text is in English, any changes you make need to be pushed to the English translation before they become visible in emails.

• Avoid using the same templates for multi-language messages and for single-language messages. Templates for single language messages must contain the full HTML code (including opening and closing <HTML> and <body> tags). Templates for multi language messages ideally should not contain <HTML> or <body> tags, as these tags are provided by the wrapping multi-language template, and otherwise the message that is produced contains invalid HTML.