How is the short description in an Incident populated from the alert?

[patrickkenney]

For Event Management we are sending events to ServiceNow using the REST api. There is only one field for description appropriately named Description. When an event moves to an Alert and then to an Incident, the Short Description is added. I would like to know how and where this is being managed so that I can tailor my events to contain information that can be split into the Short and Detailed descriptions. Example:

Event received with a Description of "Disk threshold violation on Drive C:" There is additional detail I would like to pass such as all of the information around the other drives on the server. Is there a default separator that will split the short and detailed description or is it just a truncation at a certain character count?

[Alexander Mitov]

Hello Patrick,

In my opinion the current options for incident generation from alerts are somewhat limited. I will explain below what I mean by that.

When you create the alert rule for incident generation, you will be presented with an option to create/select a task template. These templates are capable of adding static values, which is next to useless in most cases. To provide an alternative for customization, the developers have provided us, mere mortals, with the option to leave the task template field empty. When this is done, the "EvtMgmtCustomIncidentPopulator" script will execute instead. By default it does nothing - it is there, so that you could add specific code and set up dynamic field transformation and/or mapping there. This is also explained in the documentation:

Create a task template for alert rules

Dynamically assign fields from alerts to its associated task

I am sure that in a distant future release we will get an option to do this via UI, but currently there is none and this script is our only option. If you use it, I would suggest that you add logic for filtering sources if you have more than 1 source and you need to apply this logic only for a specific one OR if you need to handle incidents from different sources differently. For example:

var EvtMgmtCustomIncidentPopulator = Class.create();

EvtMgmtCustomIncidentPopulator.prototype = {

      initialize: function() {

      },

      type: 'EvtMgmtCustomIncidentPopulator'

};

EvtMgmtCustomIncidentPopulator.populateFieldsFromAlert = function(alert, task, rule){

  if   (alert.source == 'Dynatrace'){

<YOUR LOGIC HERE>

        }

};

I hope this is helpful to you.

EDIT:

I forgot to add - this script will be executed when an alert is created as the alert rule will run for new alerts. For updating the incidents when the corresponding fields are changed in the alerts, you should implement the same logic in a business rule. Whether this would be needed at all depends on the given scenario, but if the fields you need to map/transform are subject to change during the lifespan of the alert, then a business rule would be a good idea.