In the portal: Settings, then Configurations, for the three templates. Journeys for an email a journey sends.
What it is
Email is the only channel that can carry a real message with a link in it. The platform sends it in two quite different ways, and the difference matters more than anything else on this page.
Three account emails come from templates you can rebrand. They cover inviting somebody, inviting a member of staff, and resetting a password. Each one has a subject, a body, a sender name and a sender address that your tenancy can override.
A journey can also send an email of its own. That one is written on the journey node, it goes to that journey's participant, and it has no template behind it.
The three templates cover account events, and the journey action covers everything else. An email when somebody finishes week three is written on the journey node.
The three templates
| Template | When it is sent | Default subject |
|---|---|---|
invitation | Somebody is invited to join a tenancy as a participant. | You're invited to join {{tenant_name}} |
staff_invitation | Somebody is invited with any role above participant. | You've been given {{role_name}} access to {{tenant_name}} |
password_reset | Somebody asks to reset their password. | Reset your password |
The two invitations are separate templates rather than one template with a switch inside it. That is deliberate. The staff email has to say which role it grants, so somebody who was never meant to have staff access has a reason to query it before they claim it.
The staff invitation may not be listed on an older tenancy. It still sends, using the platform starter design. Ask us to add it to your list if you want to override the wording.
The merge tags
A merge tag is a placeholder you write into a subject or a body, and the
platform swaps it for a real value when it sends. Write it as two braces around
the name, like {{tenant_name}}. Spaces inside the braces are allowed.
| Tag | Available in | What it resolves to |
|---|---|---|
recipient_first_name | all three | The person's first name. |
tenant_name | all three | The tenancy's name. |
claim_url | invitation, staff_invitation | The one time link that gets them into the app. |
role_name | staff_invitation | The name of the role being granted. |
reset_url | password_reset | The one time link to set a new password. |
expires_in | password_reset | How long the reset link lasts. Today it says 1 hour. |
Two of these have a fallback. recipient_first_name becomes the word there
when the platform has no first name for that person, so the greeting reads "Hi
there,". tenant_name becomes an empty string, so a subject of Welcome to {{tenant_name}} sends as "Welcome to ". Write any sentence carrying tenant_name
so it still reads if the tenancy has no name set.
When you would use one
You do not choose to send these. They fire on their own when somebody is invited or asks for a reset. What you choose is what they look like.
Email fires on account events and on journey nodes. A scheduled check-in appearing
on somebody's home screen is not one of those, so put a sendEmail action on the
journey node when a due item should also arrive by email. See
The channels.
A worked example. A tenancy runs a workplace wellbeing programme under its
own brand and does not want the platform's name anywhere near the invitation.
They override the invitation template with their own body, set the sender
name to their programme name, set the sender address to one on their own
domain, and leave the two links exactly where they are. Nothing else about the
invitation changes: the same event fires it, the same link is inside it.
The controls
Each template has one entry per tenancy, holding four things. One tenancy sends one wording per template, so two programmes that need different invitation wording are two tenancies.
| Setting | What it accepts | Default | What changes |
|---|---|---|---|
subject | text, with merge tags | the template's own default subject | The subject line. |
html | a full HTML email | the platform's starter design | The whole body. |
fromName | text | the platform's own name | The sender name the reader sees. |
fromEmail | an email address | a no-reply address on the Intervengine domain | The sender address. |
Each setting falls back on its own. Overriding the subject and leaving the body alone gives you your subject on the platform's starter body. You do not have to replace all four to change one.
Keep a merge tag in your subject if you want the tenancy name in it. The default
subjects carry {{tenant_name}}, and a plain sentence replacing one sends without
the tenancy name.
Set fromName and fromEmail together or not at all. A tenancy's own
sender name over the platform's no-reply address is the combination that reads
as a mistake to the recipient.
How it renders
The plain text version is made for you. Every email goes out as HTML with a plain text alternative derived from it automatically, wrapped at 80 characters. There is nothing to write and nothing to override. Whatever the HTML says, the text version says the same thing without the styling.
Links are never rewritten, so the handoff into the app always works. A rewritten tracking link breaks that handoff and dumps the reader in a browser instead, so click tracking is off and stays off. Open tracking is unaffected.
Check every tag name against the table above before you save. A tag the platform
does not recognise is substituted with an empty string, so a misspelled
{{tenant_nmae}} sends the sentence with a hole in it. Reading the tag names out
loud is the quickest check there is.
The journey email is a different thing
A journey node can carry a send-an-email action. It is useful and it does not behave like the three templates.
| Template email | Journey email | |
|---|---|---|
| Who it goes to | whoever is being invited or resetting | always that journey's own participant |
| Subject and body | your override, or the platform starter | written on the node, every time |
| Merge tags | substituted | not substituted |
| Sender | your fromName and fromEmail | the platform default |
Write a journey email that reads correctly with no name in it. The subject and
the body go out exactly as typed, so a {{recipient_first_name}} token reaches the
reader as those literal words.
Telling a coach
A journey email cannot go to a coach. It always goes to that journey's own participant. When something in a journey needs a coach's attention, add a Create a task action instead. The task lands on the portal's Tasks list with the participant's name on it, and the Tasks menu shows a count of open tasks.
Three things to know when you use a task in place of an email:
- Nobody is emailed. A coach sees a task only when they open the Tasks list. Make checking that list part of each coach's day, or a task can sit there unseen.
- Every coach in the tenancy sees it. A task raised by a journey is not assigned to anyone. It stays on the shared list until a coach marks it done.
- The wording comes from the task type. In the builder you pick a task type, and the task takes its name, description, priority and due date from that type. Make one task type for each reason a journey raises a task.
Build your first programme walks through making a task type and adding the action, with screenshots.
Next
Three templates, four settings each, and every one of them falls back on its own, so you can change a sender address or a subject line without rewriting a body. That is enough to send an invitation that carries your programme's name, your sender address and none of ours, with the links left exactly where they are.
The channels sets email beside push and text messages, so you can see which of the three reaches whom.