[quote=“Colby.Clegg”]First off, we have to clarify where things are happening, and where they’re defined, and what’s different than before:
Emails are sent by Email Notification Blocks. The block defines a subject and message. These are evaluated according to each alarm that is pass through them. The can reference properties of the event. Referencing tag values here probably wouldn’t make sense, because the tag value wouldn’t really apply to all of the different alarms coming through. Basically, it’s best to think of this message like the “default” alarm message in pre-7.6 version.
On the alarm you can define properties, including custom properties, which can be just about anything (and can reference tags, properties, etc), and in turn you could reference these in your notification block, if you wanted. HOWEVER…
There is also the idea of “extended configuration” properties, which is not fully implemented in the version that is currently up. These are properties on the alarm that are added by other systems. For email, there will be “Custom Subject” and “Custom Message” properties that will be added. If these are filled in, the email block will use them, otherwise they’ll use the default. When you upgrade and your alarms are converted, these properties are currently created- it’s just that they currently show up as associated data, since we haven’t connected the dots yet.
Ok, so long story short, everything will continue to work as it did before. It’s just that now you have more flexibility in defining the default message for an email notification profile.
will these extended configuration properties be included in a csv export of a tag? currently, we just export out a tag folder, search and replace the devicename, then import back in and all of the alerting configuration for the device is correct. will things stay the same in that regard or will we now have to do some additional configuration with the new alerting system?