Template tags are used as placeholders for specific pieces of information that eLogii users want displayed in their Email and SMS notifications.

How Template Tags Work

An email template can include any Task field by using its designated name as a placeholder enclosed in double curly braces (e.g., {{contactName}} or {{location.address}}). eLogii automatically replaces each placeholder with the corresponding Task value when the email is sent.

Placeholders can be used in the Heading (subject), From name, Contents, Bottom contents, and HTML layout fields.

Placeholders must not contain spaces inside the braces. For example, {{location.city}} will be recognized and replaced with the corresponding value, whereas {{ location.city }} will not be recognized and will remain unchanged in the email.

Placeholders can contain only letters, digits, underscores (_), and periods (.). If a placeholder does not match an existing field, it is replaced with an empty value.

Placeholders do not support helpers such as fallback values, conditional logic, or formatting instructions within the braces.

Two types of values are available for use in email templates: Processed fields, which eLogii calculates or formats for the email (e.g., ETA, time windows, and the tracking link), and Task fields, which use the raw values stored on the Task.

Organizations still on the old notification system render templates differently; see the last section

Processed fields

As mentioned, these values are not stored on the Task in this form. Instead, eLogii calculates or formats them when the email is sent.

Use processed fields for any time, date, or link displayed to the customer.

For pickup notifications, the contact, ETA, time window, code, and instructions fields are taken from the pickup details of the Task. For delivery notifications, these fields are taken from the delivery details.

Placeholder	What it shows	Example output
`{{arrival}}`	ETA in the stop’s local timezone. Follows the tracking-page settings: hidden ETA shows, a custom ETA message replaces it, an ETA interval shows a range around the ETA (rounded to 15 min). No ETA yet shows `-`.	`Oct 13, 2026 (Tue), 14:22` or `Oct 13, 2026 (Tue), 13:45 - 14:45`
`{{timeWindow}}`	First time window of the stop	`09:00 - 12:00`, `after 09:00`, `before 12:00`, empty if none
`{{date}}`	Task date as DD/MM/YY (replaces the raw task date)	`13/10/26`
`{{trackingLink}}`	Customer tracking page for the task (`{{trackingUrl}}` is the same)	`https://...`
`{{contactName}}`	Contact name of the stop	`Jane Smith`, `N/A` if empty
`{{contactPhone}}`	Contact phone of the stop	`+44 7700 900123`, `N/A` if empty
`{{contactEmail}}`	Contact email of the stop	`jane@example.com`, `N/A` if empty
`{{code}}`	Identity code the customer gives the driver	`4821`, `N/A` if none
`{{instructions}}`	Instructions of the stop	`Leave at reception`, `N/A` if empty
`{{failedReason}}`	Why the task failed	`Customer not home`, `N/A` if empty
`{{taskUid}}`	Task UID	`T-AB12CD34`
`{{taskReference}}`	Task reference	`ORD-10045`
`{{externalId}}`	Task external ID	`SO-99812`
`{{companyName}}`	Company name from support settings, else the organization name	`Acme Deliveries`
`{{supportEmail}}`	Customer support email from support settings	`help@acme.com`, `N/A` if not set
`{{supportPhone}}`	Customer support phone from support settings	`+44 20 7946 0000`, `N/A` if not set
`{{supportUrl}}`	Customer support URL from support settings	`https://acme.com/help`, empty if not set
`{{qrCodeUrl}}`	Image URL of the identity code as a QR code; only set when the template has the QR code option on, and the task has a code	`https://.../4821`

Task Fields

Any field stored on the Task can be used as a placeholder. Use the field name exactly as it appears in the Task data, including the names used in Task imports and the API. To reference a field nested inside another field, join the names with a dot (.). For reference, use eLogii's API page to find the field names.

Follow these steps:

Find the field - For example, the delivery city is stored in the city field inside location.
Join nested field names with dots - Start with the outer field and work inward: {{location.city}}.
Reference list items by position - List positions start at 0. For example, the description of the first item is {{items.0.description}}.
Match field names exactly - Field names are case-sensitive, so {{customData.Brand}} and {{customData.brand}} refer to different fields.

Here are a few examples of how functional placeholders should look:

Placeholder	Shows
`{{location.address}}`	Delivery address line
`{{location.city}}`, `{{location.postCode}}`, `{{location.country}}`	Delivery city, post code, country
`{{pickup.location.address}}`	Pickup address line
`{{customData.yourField}}`	Any custom field, by its key
`{{customer.reference}}`	Reference of the linked customer
`{{assignment.assignee.info.firstName}}`, `{{assignment.assignee.info.lastName}}`	Assigned driver’s name
`{{assignment.routeUID}}`	UID of the route the task is on
`{{orderValue}}`, `{{productCode}}`, `{{priority}}`	Order value, product code, priority
`{{items.0.description}}`, `{{items.0.code}}`	First item’s description and code

Custom Data

Custom data content is commonly displayed in notification messages. For example, a custom field called orderNumber on the Task will be written as customData.orderNumber}}.

Driver Name

The Driver's name is stored on the task in two parts: {assignment.assignee.info.firstName}} and {{assignment.assignee.info.lastName}}.

The driver is only known once the Task has been assigned, so emails sent before that point (such as Task created or scheduled) will show an empty name. Use the driver’s name only in on the way, arrived, and later emails.

Many drivers are set up with just a first name, or with their full name entered in the first name field. Check how the customer’s drivers are set up, and if lastName is empty, use {{assignment.assignee.info.firstName}} on its own.

Vehicle details - The same block also contains the vehicle details: {{assignment.assignee.info.vehicleInfo.name}} and {{assignment.assignee.info.vehicleInfo.licensePlate}}.

Use Case Example

This example shows an "on the way" email that mixes processed fields (ETA, window, code) with raw Task fields (address, custom data, driver name).

The heading would contain the following text:

Your order {{taskReference}} is on the way

The message body would contain the following message:

Hi {{contactName}},

{{assignment.assignee.info.firstName}} is on the way to {{location.address}},

{{location.city}}.

Expected arrival: {{arrival}} (your window: {{timeWindow}}).

Order number: {{customData.orderNumber}}

Your delivery code: {{code}}

The bottom text content would be the following:

Questions? Call {{supportPhone}} or email {{supportEmail}}.

In the email customizer, it would look something like this:

To add something the toolbar cannot make, such as a second button linking to the customer's own site, edit the HTML tab and place it next to the existing tracking button, e.g. <a

href="https://acme.com/orders/{{customData.orderNumber}}">View your order</a> .

Send Conditions

Depending on which notification system is being used, send conditions may apply differently.

Advanced Notification System

The Advanced Notification System does not support conditions within a template. Instead, conditions determine which template is sent, or whether the notification is sent at all. Both are configured under Settings ⇒ Notifications, by opening the relevant event.

Template rules: Determine which template to send based on task conditions. For example, Tasks with the custom field vip = true can use a VIP delivery template, while all other Tasks use the default template. If multiple rules match, the last matching rule in the list takes precedence.
Send conditions: Determine whether a notification should be sent. All configured conditions must be met for the notification to be sent. If any condition is not met, the notification is not sent.

Both types of conditions use the same field picker as Task rules, allowing you to check any Task field, including custom fields, customer details, tags, and priority.

To display different versions of the same sentence, create two separate templates and use a template rule to select the appropriate one based on the Task's conditions.

Legacy Notification System

Within the legacy Email and SMS notification system, conditions can be written inside the template.

Goal	What to write	Field to write in
Pick one of two texts	`{{customData.vip ? "Dear VIP customer" : "Hello"}}`	any field
Fallback for an empty field	`{{location.address \|\| "Unknown address"}}`	any field
Check a value	`{{state === 60 ? "Delivered" : "On the way"}}`	any field
Show or hide a whole block	`<% if (data.customData.vip) { %>VIP text<% } else { %>Normal text<% } %>`	HTML tab only

Rules for the legacy notification system

Field references: Expressions must start with a field name. When referencing a second field in the same expression, prefix it with data.. For example: {{customData.vip ? data.customData.brand : ""}}.
Supported characters: The operators <, > and && can only be used in the HTML tab or the heading. In the Contents and Bottom Contents fields, these characters are converted to other characters, which can break the expression.
Test after every change: A broken expression prevents the entire email from being sent to the customer. Always send a test email after making changes to verify that the expression works correctly.
Switching to the new system: The new notification system doesn't support these expressions. After the switch to the new notification system, expressions will appear in the email exactly as entered instead of being evaluated. Replace them with template rules to achieve the same conditional behavior.

Important to Consider

Raw values are not formatted. Some placeholders return the raw value stored in the task rather than a customer-friendly format. For example:
- {{estimates.arrived}} returns a Unix timestamp in seconds, e.g. 1760365320.
- {{timeWindows.0.start}} returns the number of minutes since midnight, e.g. 720.
- {{dateRange.startDate}} returns a date in YYYYMMDD format, e.g. 20261013.
Use the processed placeholders {{arrival}}, {{timeWindow}} and {{date}} instead when displaying these values to customers.
Use the correct address fields. The placeholders {{address}}, {{city}}, {{postCode}} and {{country}} are listed in the dashboard's placeholder reference but are not populated in Task emails. Use {{location.address}}, {{location.city}} and the corresponding fields instead.
Pickup and delivery addresses are handled differently. The location object always refers to the delivery location. In pickup notifications, {{location.address}} still returns the delivery address. Use {{pickup.location.address}} to display the pickup address-
Formatted and raw dates are different. {{date}} returns a formatted date, not the raw stored value. The raw date is not available through this placeholder.
Placeholders do not support helpers or custom logic. In the new system, placeholders can only return values. They do not support fallback values, conditional expressions, or date formatting. For example, {{location.address || "Unknown address"}}a condition such as displaying "Good morning" before noon, or a date-formatting expression will not be evaluated. Instead, the expression will appear in the email exactly as entered.

Empty fields display nothing. Only certain processed fields have built-in fallback values, such as N/A or - (see the placeholder reference table). Write surrounding text so that it still reads naturally when a field is empty. For conditional content, use template rules instead (see Conditions).
The preview may not match the sent email. The dashboard preview is more forgiving: it accepts spaces inside braces and displays unknown placeholders as {{...}}. The sent email does neither. For example, {{ location.city }} will remain unchanged in the email, while unknown or empty placeholders display nothing. Always send a test email to verify the final result.
Reference individual values, not entire objects or lists. A placeholder referencing an object, such as {{location}}, displays [object Object]. A placeholder referencing a list displays its values joined by commas. Use a placeholder that points to a specific field whenever possible.
Values reflect the Task when the email is sent. Placeholders use the values stored on the Task at the time of sending. Changes made to the task afterward do not update emails that have already been sent.
Driver notifications have limited placeholder support. Driver notifications do not have access to all Task fields. The available placeholders are {{driverName}}, {{driverEmail}}, {{driverPhone}}, {{taskUid}}, {{taskReference}}, {{date}}, {{contactName}}, {{address}}, {{customData.*}}, {{routeDate}}, {{taskCount}} and the company/support fields.

Legacy notification system - What to consider

Organizations that have not migrated to the new notification system still use the legacy email templates.
Task fields work the same way in both systems, but the legacy system supports only the following processed placeholders: {{arrival}}, {{timeWindow}}, {{date}}, {{trackingLink}}, {{contactName}}, {{contactPhone}}, {{code}}, {{instructions}}, {{failedReason}}, {{companyName}}, {{supportEmail}}, {{supportPhone}} and {{qrCodeUrl}}.
For Task identifiers, use {{uid}} and {{reference}} instead of {{taskUid}} and {{taskReference}}.
Legacy templates also support simple calculations and conditional logic, such as displaying a greeting based on the time of day, as well as fallback values like {{location.address || "Unknown address"}}.

Important: These expressions are not supported in the advanced notification system. When an organization migrates, remove them from its templates and replace conditional behavior with template rules. Otherwise, the expressions will appear in the sent email exactly as entered.

SMS and Email Template Tags