Including Action Name or ID in Alert Action

To the best of my knowledge we do not have 'action name' variable, i generally keep my alert name and action name the same (the only modification to the action name that i define would be with a postfix as - trigger or - reset)

If the AlertName is: Node Down

Trigger ActionName that i define would be: Node Down - trigger

Reset ActionName that i define would be: Node Down - reset

I follow this to track them easily when required, if you have multiple actions just add a postfix after trigger for example if its an email in your Trigger then name it as: Node Down - trigger - email

Common variables are mentioned in the below link:

https://documentation.solarwinds.com/en/Success_Center/orionplatform/Content/Core-General-Alert-Variables-sw1121.htm

Apart from this you have few additional variables as well like the one you mentioned but i am pretty sure i haven't seen a 'Action Name' Variable so far.

Hope it helps.

Same here, naming convention is key -- couldn't agree more. Unfortunately nothing native to pull in the ActionID. There's no easy SWQL navigation properties to get at the ActionID. The issue really comes down to that fact that the Alert is the reference point and you can tie many upon many actions (in different escelation levels for triggers) and resets as well.

If you really want to get complicated with it... there are options if you know how to appropriately filter it down to the action you want. Here's something to get you started poking around.

-- This query is more just for testing in SWQL studio
-- You cannot have multiple outputs in a custom SWQL variable
SELECT ac.Name, ac.AlertID, ac.AlertRefID, aa.CategoryType, a.Title, a.ActionID, a.ActionTypeID
FROM Orion.AlertConfigurations AS ac
INNER JOIN Orion.ActionsAssignments AS aa ON ac.AlertID = aa.ParentID
INNER JOIN Orion.Actions AS a ON aa.ActionID = a.ActionID
WHERE ac.AlertID = 68

-- This is a custom SWQL variable that COULD be used to pull the Action Title
-- Note I'd probably do a bit more filtering (maybe a.Title LIKE 'Standard Email%' ) etc.
${N=SWQL;M=SELECT a.Title FROM Orion.AlertConfigurations AS ac INNER JOIN Orion.ActionsAssignments AS aa ON ac.AlertID = aa.ParentID INNER JOIN Orion.Actions AS a ON aa.ActionID = a.ActionID WHERE ( ac.AlertID = ${N=Alerting;M=AlertID} AND a.ActionTypeID = 'Email' )}

perfect, thank you.

Interesting approach. Do you have a 1:1 alert:action ratio, or close to it? I've tried to generalize actions as much as possible by using custom properties for recipients and by putting the specific message in the alert itself. There are times when this isn't perfect, but overall, it results in a much simpler list of actions to manage.

Yes, its much easier that way, i have been doing this on quite a lot of projects (clean up). Most of the alerts in my environment are generic and i play around with custom attributes.

Nerveless i do not like too many individual alerts and have managed to make them as generic as possible.

It isn't that simple to get into a agreement with all platform teams though  

Sometimes it as well happens that they are not happy with generic thresholds, hence for certain teams i have scheduled reports on a daily basis, since they are 24X7 a single report is sent to specific teams which highlights outstanding alerts that still need action by their team little tweaks here and there though.

When you are in a 24X7 support it as well happens that every request is an urgent request so platform teams would push you to get their stuff done, it ain't easy for monitoring teams if they do not have a well defined process in place, hence i generally create few templates for onboarding devices, deletion of devices, reports, alerts etc and worst case scenario if its all together a new requirement then we look at the long term plan and specific/custom alert creation would be created on temporary basis

The problem that i have noticed over the years is, when you take over an existing SolarWinds environment from someone else who was managing it, there are lot of bits and pieces that are not in place, lot of things like unwanted reports, alerts, custom attributes, undp pollers, views, accounts etc etc. The first thing that i always do it create a As-Is document and then cleanup the environment, remove all that is unwanted from your environment and create a process document that the admins need to follow when they are onboarding or removing stuff from SolarWinds. This simplifies the entire process on handling your environment and most importantly when you move out of the project the new guy who takes over stuff from you would indeed be very happy to see a clean setup

While my team is working on day to day activities i am working on such things hehe

Most people will not agree with me and they might counter me stating why cant we reuse the actions for multiple alerts, when i say my alerts are generic why cant we reuse the actions make it more generic lol 

Definitely yes we can do that as well, but then the catch there is, it becomes difficult to mange your actions, rather work on your alerts, reduce them as much as possible and keep a 1:1 mapping between alerts and actions which share the same name