Using a Macro for email alerts in Advanced Alert Manager

Thanks for stumbling on this!  I had no idea it was that easy, now I can re-configure all my alerts. 

During my testing, I found that not having an email address in the Primary Contact field didn't appear to break anything, just didn't send the email.

Glad I was able to help.  Thanks for your response it's good to hear that this doesn't seem to break anything.

I am thinking that this could be pretty useful going forward.

byrona,

Thanks for posting; it's always great to see community members help each other.  I haven't tested this myself, but jainsworth's observations sound right; it just won't send an email.

-Craig

I guess my next question regarding this for SolarWinds would be; is this intended behavior and therefore will it stay around and not be removed at some point?

I ask because I think this is awesome but would hate to build a bunch of stuff that relies on it only to have this functionality go away.

Hey, just because I am paranoid doesn't mean they aren't watching!  = )

It's definitely intended behavior and you're safe to use this feature.  In fact, I think I might use your idea for my next Orion Product Blog post   I've entered a tracking item to ensure we don't forget to account for this use-case in any future revamp of alerting.  

Sweet!  Thanks so much Chris!

Actually you can have a blank field and 1 separator like ; or ,

I posted a similar  hint -- .

You can combine multiple custom fields to compose another custom field.

Custom field: Alert_Email   contains ${Node.MailTo1};${Nodes.MailTo2}  <--- ${Node.Alert_Email} goes in the To: field of Alert.

Custom field: MailTo1    <--- auto populated

Custom field: MailTo2    <--- exposed on the customer dashboard so they can update themselves.

There's definitely a lot of creative things you can do to simplify your life.

- v

viol8tor

Thanks for this additional info.

How do you hide some fields while allowing your customers access to modify other fields?  This is something I might like to do if I knew how.

In the device / node view you have assigned to your client, add "Edit Custom Node Property" from Miscellaneous - Miscellaneous Resources.

Once added, go back to the device / node view and Edit and assign the specify the custom property field you want them to have access to.

Repeat for each Custom Property you wish for them to have access to.  Users can update these fields without Admin rights.

On devices that have a lot of custom properties (20 or more), I create a separate view just for the Custom Properties and link it to their node page via "User Links".

In the custom URL of "User Links" resource, add the following code: /Orion/NetPerfMon/NodeDetails.aspx?viewid=XXX&netobject=N:${NodeID}

 - Where XXX is the ViewID number of the view that contains the a list of custom properties they can edit.

For Administrators (that do not have SW Admin rights), I create a report that I turn into a "Web Resource" which will also launch a special view that will allow them to edit their custom properties.

(This is useful for updating Site information, like Addresses, phone numbers, etc.  The report is an easy way to list relevant data without having to drill down through each node.)

- When creating the report in Report Writer, make sure to add the "Status Icon" as one of the fields. (The nodeid should be there by default, if not add it and hide it.)

To the "Status Icon", in the Field Formatting Tab, add the following code to the Web URL /Orion/View.aspx?ViewID=XXX&NetObject=N:${NodeID}

 - Where XXX is the ViewID number of the view that contains the a list of custom properties they can edit.

When viewing the report on the website, the users can click on the "Status Icon" which will send them to a different view which will allow them to update the custom property records.

This is all good for simple 1 off changes.  For anything else, I still prefer to do it directly in SQL.

-v

@Byrona - thanks for sharing - this Idea actually came to me in the shower (of all places) this morning - But I couldnt figure out what the variable should be called - thanks for the tip !!! this GREATLY simplifies alert handling - Solarwinds should seriously consider including this in the documentation !