...
| Ui steps |
|---|
The instructions below outline how to set up a design editor for transactional email. For example: Accompanying letter. | Ui step |
|---|
The operator is able to create a new document type or re-use an existing one and just create a new document model (step 2). Because one document type enables only one document model with the type "Email," the operator must invalidate an existing "Email" document model before creating a new document model with the new type.
|
| Ui step |
|---|
If the operator reuses the existing document type, they invalidate the existing one and create a new one.
The operator has to create a new document model with the type "Design Editor" in order to configure the new designer email template.
|
| Ui step |
|---|
If the operator does not set up a document template, the system uses the default template. If the operator wishes to customize the standard template, they need to create a new document template.
In the document template screen → A new menu "Template editor" is added. On click the designer editor is loaded and the operator is able to modify the content.
Adding merge tagsTo modify the content by using merge tags click on the editable content block and look for merge tags. The system will offer you the ones that are available for this document type.
|
| Ui step |
|---|
We recommend the operator validate the new changes to the document template before putting it into use. The contact number selected represents a link to the concrete order number where the information is stored. The system will use this information to generate a test email respecting the configuration, data, and structure of the email template and selected order example. Validating the email will provide an example as seen below.
When designing your email templates, we recommend you use a feature "Saved rows" which will make the process of applying shard design styles such as header or footer across multiple transactional emails much faster and more convenient. You have to create a row once (use save button as indicated below), store it, and simply reuse it in other email templates by finding it under Saved rows section (See below).
|
|
Multi-language support per document model
...
You will notice that every template newly created template will be generating a *.json file that is available for download. Currently (in Beta status of the release) the uploading is not yet enabled. In future releases, we'll enable the possibility to upload those templates so that you can test them first in testing environments (such as preproduction) before uploading a final version to your production environment.
Other details
Specialities
While this new functionality provides a significant improvement to how transactional emails are managed today, you will notice that some of the documentation templates are populated with some technical code conditions. This will be improved over time but for now ...
| Info |
|---|
|
We recommend NOT removing any of those code conditions and purely focusing on adapting the text associated with actual messaging. Some templates provide templates that cover multiple use cases and the text from such templates will be applied only when specific criteria of action are met before the template is generated and shipped to the end user. Such a case is the template for Orders that you can also see below. Such a template will trigger only a specific part of the messaging applied on the template respecting specific cases. An example can be when the user's order was made using the product "options" or "reservations". Removing the mentioned code from the view will break the template and require you to configure the template from scratch. 
|
Formats available
While this feature was primarily built for transactional emails, it might be useful to design other formats of documents. We also support the creation of document models in PDF format.