HaloITSM

HaloITSM Guides

Documentation to assist with the setup and configuration of the HaloITSM platform

Guides > Event Management

Event Management

In this lesson we will cover:

- Setting up Event Management

- Creating an Event Rule

- Overseeing Events 


Event management allows you to manage the events that are triggered by Asset Management and Alerting integrations using webhooks. Using this module you can create rules to determine which events log tickets and control the fields/configuration on the ticket that gets logged for a specific event. This gives you more control over the alert/ management tickets that are created from integrations, both in terms of when they are created and the data they are populated with on creation. It also allows events to update an existing alert ticket that is related to that same event. 


Throughout this guide we will refer to 'events' and 'alerts':


Events: These are anything that trigger a webhook, results in a request being sent from the integration to Halo. The event being the scenario from the integration platform that is being sent into Halo via the API.


Alert: A ticket that is created as a result of an event. The event is not solely for Alerts, it may be change management information you are ingesting into your Halo platform in order to store the history of assets. This is useful to track the life cycle and health of said assets.


Note: This guide is only applicable to RMM integrations that create alerts using webhooks. For RMMs that create alerts using emails, see our guide here. To match existing alert tickets that are ingested via email, check out this runbook guide: here


Setting up Event Management

First, head to Configuration and enable the module. 

Fig 1. Enable Module


Once enabled, ensure you and any other agents have permission to access this module. Head to Configuration > Teams & Agents > Agents > select and agent > Permissions tab, see 'Event Management Access Level'. For agents to be able to create new event management rules they will need 'read and modify' permissions. 

Fig 2. Event Management Access Level permission


Once the module is on and permissions added you will need to log out and back into Halo for this to take affect and the module to be visible. 


You should now see Event Management in your navigation menu (this may be in your overflow menu, as shown in Fig 3).


Fig 3. Event Management in navigation menu


Creating an Event Rule

Start by heading to Configuration > Event Management > Event Rules > New, here you configure a new rule.

Fig 4. Event Rules (Found in the Event Management Configuration Module)


Rules work by checking criteria set against defined variables. These variables are based on the initial payload of the webhook, therefore any criteria you would like to set needs to be based on a value present in the webhook payload. 


This means any webhooks you have set up for your Asset Management/ RMM integration(s) need to be redirected to post to the event management endpoint. To do this you will need to edit the webhook(s) you have set up for your Asset Management/ RMM alerts/ events (done within the integration platform) and change the endpoint URL to: https://{YourHaloDomain}/api/incomingevent/process


Then you will need to change the permissions of the API application that is authorising the webhook connection. Head to into Halo, configuration > integrations > Halo API > view applications > select the application authorising the webhook(s) > permissions tab, enable the following permissions:


  • edit:events
  • read:events


Then save. 


Now when an event occurs it will be evaluated by this module before creating an alert ticket. 


Defining variables 

Head back to the event rule configuration and see the 'variables' section of the event rule. Here you will first need to specify the 'Event ID variable' this is the value in the payload that is the ID of the event, used for matching the same events to the same alert ticket. This will follow the format 'request^id' where 'id' is the event ID value specified in the webhook payload. Each variable created will begin with request^.


Now define the variables you would like to be evaluated by adding a line to the variables table. You will need to give the variable a name, select the data type and provide a description (if desired). Then, in the value field, enter 'request^' followed by the key value. 


Note: The value that is the event ID must have the data type 'Object'.


For example, I am using the following payload in my webhook (this example uses the Datadog RMM):

{

    "datadog_id": "$ID",

    "security_signal_id": "$SECURITY_SIGNAL_ID",

    "summary": "$EVENT_TITLE",

    "priority_id": "1",

    "user_id": "$USER",

    "tickettype_id": "1",

    "customfields": [

    {"id": "239",

    "value": "$HOSTNAME"}],

    "new_external_link": {

       "table_id": "1",

       "module_id": "391",

       "third_party_id": "$ID",

       "third_party_url": "$LINK",

       "third_party_desc": "$SECURITY_SIGNAL_ID"}

   

}


I would like the ID, summary, priority and user values to be evaluated so I will create variables for these as shown in Fig 5. 

Fig 5. Defined variables example


Setting Rule Criteria

Under the 'criteria' section you can set the criteria for the rule, if an event matches this criteria, a ticket will be logged. 


To do this add criteria to the table, choose the variable you would like to base this on, the rule type (equal to, contains etc.) and the value. The rule types you have available to choose from will depend on the data type of the variable. 


In Fig 6 I have set the criteria so that the rule will match when the event has a summary containing 'disk space low'.

Fig 6. Example rule criteria


You can add multiple lines to this table but all criteria must be met for the rule to be matched. 


Rule Outcome

Set the rule outcome in the 'Outcome' section'.


Here you can toggle the 'Use' of the rule between Ticket Type and Template. 

Ticket Type - will let you choose a ticket type to determine what type the ticket created will be when this event occurs and this rule matches.

Template - will let you choose a ticket template to be applied to the ticket that is created when the event occurs and this rule matches. 


Once this is set you can set some field mappings, this allows you to populate ticket fields with data from the variables. 


To do this, add to the field mapping table, choose the Halo field that you would like to be populated then choose the variable you would like the data to come from.


The following fields are currently supported:


  • Custom Fields
  • Summary
  • Details (New Alerts only)
  • Status
  • Action Note (Updates only)
  • Start Date
  • Target Date
  • Priority
  • Urgency
  • Categories 1 to 4


In the Fig 7 example I have mapped the event summary to the appear in the ticket summary and the event ID to be in a custom field 'Event ID'.

Fig 7. Field mapping example


Overseeing Events

Now a rule is setup each event that meets this criteria will log a ticket with the specified values in the event rule. Any events that do not meet any criteria of an event rule will not create a ticket. 


Tickets created as a result of event management will have an event management tab, showing a log of the event and the rule they have matched with request/response info. 


Fig 8. Event management tab against ticket


If a log is selected it will open a new window showing the request and response information. 


Events can also be viewed under the Event Management module, upon opening the module you will see a list of events that have occurred, regardless if they have matched a rule and created a ticket or not. Allowing you to bulk update tickets with multiple events as explained below. The use case of this is to store the history of certain assets within one area of Halo, and 


By default these are sorted chronologically but results can be sorted/filtered by selecting the column headers. 


Fig 9. Event Management logs 


Selecting a log here will also display the request and response. 


If an event has not matched a rule, an agent with event edit permissions can process the event manually, they will have 3 options:


Re-evaluate - This will run the rule matching for that event again. This allows events to be processed if the rules have been updated since the time the event was received. Similar to how a manual ticket rule works (Guide: Ticket Rules)

Create Ticket - This lets you select a rule, the outcomes of this rule will be used to create a ticket, regardless of if the event matches the criteria

Link to Ticket - This allows you to choose a ticket to manually link the event to a ticket. None of the values will be applied from the event to the ticket, but the event will show in the ticket's event management tab.


To process, select some events, hover over 'edit' and these options will appear. 


Fig 10. Manual event processing options


General settings

Under Configuration > Event Management > General Settings, there are two settings:


  • Number of days to retain matched event logs for - Determines how long event logs are stored for events that match a rule.
  • Number of days to retain unmatched event logs for - Determines how long event logs are stored for events that do not match a rule.


Fig 11. Event Management General settings


Popular Guides

Pin It on Pinterest