Automated Emails
Introduction
This website includes a number of forms. When a user submits one of these forms, they will usually receive an immediate but temporary confirmation on-screen that the form was submitted successfully. This will be ‘lost’ when they navigate away from the page.
In addition, it is standard practice to send an automated confirmation message to whatever email address the user provided in order to:
provide the user with a more permanent receipt as proof that the form was submitted successfully
acknowledge receipt of the information that was submitted through the form
record what information was actually submitted by the user and the date and time of this was done
let the user know what they may expect to happen next, ie when they may receive a more specific response.
For each user form on the website such an automated email has already been created. The following form is provided for admins wishing to quickly and simply amend the email header and its contents.
More technical settings relating to the email may be adjusted via the control panel
Automated Email Editing Form
Please use this form to amend a pre-existing automated email. Take care to complete all required fields marked with a ‘*’.
Guidance Notes
some handy hints on how to compose your email and what to include.
Body Copy Types
The main content of an email (the body copy) can be sent in different formats or types. The following summarises the main pros and cons, before recommending that sending both plain and rich text is usually the best option.
Plain text
Plain text is recognised by all email browsers and displays exactly as it is written, eg:
The quick brown fox jumps over the lazy dog
The main benefits of plain text are that is quick and simple to compose, lightweight to send and robust and reliable to display. It’s main drawback is that it is a little, well, … plain.
It is best used for quick short messages, where style is not important.
Rich text
Rich Text is recognised by most (but not all) email browsers. It is plain text but with added <html tags> to inject some style and colour when it is displayed. So, for example:
<p>The <i>quick</i> <span style=”color:brown;”>brown <b>fox</b></span> jumps <sup>over<sup> the <sub>lazy dog</sub></p>
will display as:
The quick brown fox jumps over the lazy dog
The main benefits of rich text is that judicious use of different styles and emphasis can break up monotonous blocks of text, help prioritise information and create a more interesting layout.
Its drawbacks are that it is a bit more fiddly to compose and does require some knowledge of html. Whilst this is quite easy to learn or lookup, a little knowledge can be a dangerous thing, and, as above, one can overdo the visual bells and whistles.
Also, whilst most modern email browsers can handle rich text, they can do so in slightly different ways, leading to content being displayed not quite as intended in some browsers.
It is best used for large complex messages, such as newsletters, but even then you have to ask yourself whether these really should be sent as body copy in an email ratheh than attached as a pdf.
Both
Sending an email with both plain rich text is a belt and braces approach. Those email browsers which recognise rich text will display it, those that don’t will revert to the plain text.
In many ways this offers the best of both worlds, style and reliability. The slight downside is a doubling of memory size, as in effect the same content is sent twice, As indicated below:
The quick brown fox jumps over the lazy dog.
The quick brown fox jumps over the lazy dog
But unless recipients have a very patchy internet connection, this is not so much of an issue these days.
In many ways this is the most optimal solution for automated emails, not least because even though the email that is sent will contain both kinds of text, you only need supply the copy in rich text format. The system will automatically strip it back down to plain text for you.
Body Copy Content
Single Quotes (‘)
<_FORM_CONTENTS_>
<_DYNAMIC_CONTENT_>
some handy hints and top tips and tricks on what to include in body copy to make the most of automated emails
Also known as an inverted comma, or apostrophe,. Any such ‘ characters in the body copy must be ‘escaped’. This means that they should be immediately preceded by a backslash (\). And for good measure, so should double quotes (“) too, eg:
that previous mention was not ‘escaped’, this is \’escaped\’
don’t do that, instead, do this: don\’t
you say "potato”, I say \”po-ta-to\”
its not Jimmy’s bike, its John\’s
If you find that the your text is truncated when sent as an email, it is probably because of an un-escaped quote somewhere in the text..
The reason for this is that the body copy will be stored as a string of text wrapped in single quotes. The system will read any single quote within the text as the end of the quoted text, even if it is just there as an apostrophe to indicate possession. This will both truncate the text and cause problems with the now unexpectedly redundant text. To prevent this, all such quotes need to be \’escaped\’.
To display all the details submitted by a user through the form, simply start a new line in the body copy containing this placeholder. For example:,
… you submitted the following contents:
<_FORM_CONTENTS_>
we will process this information and get back to you …
As if by magic, all the details submitted by the user will appear in the email as follows:
… you submitted the following contents:
field name 1
user submitted value 1
field name 2
user submitted value 2
we will process this information and get back to you …
Emails sent in plain text will be similar, only without the emboldened field names.
Hidden Fields
Please note that the preceding text referred to: all the details submitted by the user , which means all the data that they entered into the visible fields on the form.
A form may sometimes also contain hidden fields. These usually contain data usually used for administrative purposes, and usually not relevant to be displayed to the user. If for some reason you need also to include all the hidden field data, use <_FORM_CONTENTS+_>
Similar to the <_FORM_CONTENT_> placeholder described above, you can also represent the name of a field anywhere in your text, and, again as if by magic, the corresponding value submitted by the user will appear in the email text, eg:
Dear <_FIRST_NAME_>
will appear as:
Dear John/Jane/Sue
to achieve this:
start with the name of the relevant field., exactly as it appears on the form. Ignore any asterisk indicating a required field. So for the first field in the form above, the field name would be: first name.
(Technically, what you actually need is the title of the corresponding sheet in google docs where the data is stored,. This is usually (but not absolutely always exactly the same as the field name on the form)
render the field name (usually shown in lower case) in UPPER CASE, eg: FIRST NAME
replace any intermediate spaces in the field name with an underscore character, eg first name becomes FIRST_NAME
immediately precede the field name with <_, (ie a less than symbol and an underscore)
immediately follow the field name with _> (ie an underscore character and a greater than symbol).
So, putting the whole thing together, the field: first name* is represented by the placeholder: <_FIRST_NAME_>