Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Variables in the to field of Email Action Solved!

As of SAM 6.5 and I'm assuming more importantly Core 2017.3.4 you can now use complex variables in the TO: field of a send email action in advanced alerts!

In the below example we have 2 custom properties on groups. One property holds the email for that group (group_email) which is where the alert gets sent. The second property (Is_Distro_Group) is a bit (yes/no) custom property that determines if that group is used for alerting. This was needed as we have other groups that aren't used just for alerting and we needed a way to differentiate them.

For production use you would want to change the EntityID=1 to something like EntityID=${N=SwisEntity;M=NodeID} This would allow the alert to identify the group that the node is a member of and use that group's group_email property to send the alert

In the container table EntityID is not just for nodes, so its important to filter to whatever you want for your case as you can see by EntityDisplayName='node'

At any rate we are very excited this works now. We can finally scrap our custom send mail action which was an ugly external vbscript!

Message was edited by: Ryan Davis - changed EntityID='${N=SwisEntity;M=NodeID}' which wouldn't work as single quotes around the nodeid variable doesnt work to EntityID=${N=SwisEntity;M=NodeID}

Find more posts tagged with

Accepted answers

All comments

Seashore

At one customer we use these kind of variables in the to-feild:

${N=SwisEntity;M=Node.CustomProperties.Site}_Solarwinds_Larm@custom.com

Where the custom property "site" is a mandatory field telling where the node is places and "site_solarwinds@customer.com" is a distribution group for each site. Works pretty good.

ryan.davis26

Not a bad idea. Our customer needed to have groupings of devices by function rather than location. So we actually have about 60 groups of devices by function or system owner really, and that group only gets emailed for devices in that group

We could have gone the custom property route and just store the email in there, but this would leave it open for errors. We essentially have a node custom property that defines what group the node should be a member of. The group itself than has a dynamic query based on that node custom property. So all my configuration guys have to know is what group the device should be in when adding new devices.

Seashore

Ok, but working with Custom Properites you can have them "required" so you don't miss a node and don't get alerts on that one. Groups are not mandatory (if you don't populate them dynamicly and automaticly).

Guess you also could build the email-address from several custom properties like: [Device-Type].[Site].solarwinds@customer.com

But it will be alot of distribution-groups in the mailsystem.... :-)