Skip to main content

Using tokens in your automation text

Where an automation asks you to write text, you can drop in tokens that get replaced with the real details when the rule runs. It's a small feature that makes a large difference to whoever reads the record afterwards.

Why it matters

When an automation takes a vehicle out of service, the reason you wrote is the entire explanation anyone gets. It appears in the asset's out-of-service log, and it's the first thing read by whoever is trying to work out why a vehicle is unavailable.

An out of service log entry reading: Asset was marked out of service by a workflow automation

A reason written without tokens. It is accurate, and it tells the reader nothing they didn't already know.

A reason that says Asset was marked out of service by a workflow automation is accurate and tells them nothing. They still have to go and find out which automation, and what it was reacting to. A reason built with tokens answers those questions in the log itself.

Available tokens

Token

Replaced with

{{formName}}

The name of the form the inspection was submitted on

{{assetName}}

The asset the automation acted on

{{automationName}}

The name of the automation itself

Using them

Type the token into the text field exactly as shown, including both sets of braces. You can mix tokens and ordinary words freely, and use the same token more than once.

Nothing is substituted while you're editing — you'll see the raw token in the field. The replacement happens when the automation runs.

Because {{automationName}} pulls in the rule's name, renaming an automation changes what future entries say. Past entries keep the text they were written with.

Examples worth copying

For an out-of-service reason

Out of service after a failed {{formName}} — raised automatically by {{automationName}}

Reads in the log as: Out of service after a failed Accident Report — raised automatically by Critical defect on accident form submission. Someone seeing that knows what happened, what triggered it, and which rule to look at if it was wrong.

When the fleet is large enough that the vehicle isn't obvious

{{assetName}} failed its {{formName}} and has been taken out of service pending inspection.

When you want to point people at a process

Automatic hold after {{formName}}. Contact the shop before returning {{assetName}} to service.

The log entry becomes an instruction rather than just a record, which is useful when the people finding the vehicle aren't the people who built the rule.

Did this answer your question?