[bug-4173, 4176]Alarming Custom Messages - Upgrading 7.x to 8.x

Hey folks,

I ran into some unexpected lost time and frustration with the upgrade and custom alarm email messages. I didn’t see anything about it in the upgrade guides, so I wanted to share it here in case anyone else runs into the issue.

Basic Custom Message Formatting

The gist of it is that custom alarm messages are not required to be bound as expressions in 7.x, but 8.x requires it. With this comes a change in formatting, and these changes are not automatically resolved by the upgrade.


I worked with IA tech support and briefly touched on the issue here. For anyone that referenced the 7.7-7.9 IU Alarming video “Custom Email, SMS, and Voice Scripts”, you may have followed the tutorial and written your custom message directly into the “custom message” box as follows:

At {eventTime|hh:mm:ss}, alarm "{name}" at "{displayPath}" transitioned to {eventState}.

In 8.x, the way Ignition is evaluating this message and passing it to the alarm pipeline has changed, and the message must now be an expression binding rather than typed straight into the box, and it must be formatted as a string and wrapped in quotes:

'At '+"{eventTime|hh:mm:ss}"+', alarm '+"{name}"+' at '+"{displayPath}"+' transitioned to '+"{eventState}"+'. '


  • Copy the custom messages and reformat / wrap them with quotes as needed into an expression binding.

Associated Data named “value.”

Today I found that having associated data on an alarm named “value” will resolve initially but break in time, thereby breaking the custom message. Again, something developed in 7.x that does not work in 8.x

When adding associated data (say you wanted to show analog data related to the alarm), if you name that associated data “value,” you can bind it to a tag and it will evaluate. However, after cycling the tag provider (or presumably power), those bindings are broken and so are the custom messages they are associated with.

Value: {[~]Well/Level/Domestic_Level}

Custom Message:'At '+"{eventTime|hh:mm:ss}"+', alarm '+"{name}"+' at '+"{displayPath}"+' transitioned to '+"{eventState}"+': '+"{Value}"+" in."

Evaluates as: (Ignition Alarm Notification) At 03:38:10, alarm Domestic Water Low at Well transitioned to Active: 43 in.

After cycling the tag provider, the Value tag binding will become the following:

Value: [{     "bindType": "Tag",     "value": "[~]Well/Level/Domestic_Level" }, Good, Wed Aug 25 16:22:19 PDT 2021 (1629933739159)]

Though in the case of the gateway I was troubleshooting, all the bindings looked like this:

[, Good, Wed Aug 25 16:22:19 PDT 2021 (1629933739159)]

The custom message now evaluates as:

(Ignition Alarm Notification) At {eventTime|hh:mm:ss}, alarm {name} at {displayPath} transitioned to {eventState}:{Value} in.

Removing the quotes from around {Value} will evaluate as:

(Ignition Alarm Notification) At 03:38:10, alarm Domestic Water Low at Well transitioned to Active: true in

Which suggests to me that the value binding may looking at the value of the alarm, not the “Value” associated data.


  • Manually changing the name of the “Value” associated data to something else (data, level, analog) and updating each binding seems to resolve the issue. With a large system, it can take quite a bit of time to get these functioning again.

If anyone has any insight or can add to this, I welcome the feedback.

I think I touch upon that in my list of v7 to v8 things here

I can’t promise timelines or indeed, whether anything about this will change, but I filed tickets so we can investigate this and see if we can change something.

1 Like

Sorry for the confusion, but we’ve just looked over the tickets, and here’s what we’ve found:

  1. It was never intentional that the format of CustomMessage should change. People have gotten confused between that setting of an alarm, which is a string template that is evaluated by the notification pipeline, and other concepts like bindings on tag properties. They’re not related, and it’s purely a mistake that CustomMessage with the 7.9 style string was being interpreted as an expression. The workaround works because it makes it a valid expression that… results in a string that is equivalent to what you would type in 7.

  2. A custom property on an alarm called “value” would essentially “shadow” the system property of that name (which is not so much a property, as a special keyword that can be used in alarm expressions). I would say that that should be allowed, and should always resolve to the custom property. It sounds like it’s doing that on creation, but not after reloading the tag.

We will prioritize both of these issues to get them resolved ASAP.

1 Like

Thank you Colby and Paul. I appreciate the quick response!