About Actions and Action Groups

Processes in LM Dexda involve an action group which is a sequence of actions with the purpose to accomplish a specific goal. This article describes the concept of actions and action groups, and how they are related. For more information on how to work with action groups, see Creating Action Groups.

Actions

An Action is a preconfigured capability to for example update an alert, or create an incident in ServiceNow. Actions are always associated with an Action Group.

Action execution consists of load, mappings, and execution. All actions will execute their “load” phase, which when applicable may load any existing record, or test whether one already exists, to support the preconditions being evaluated.

If the condition is not then matched they will finish with an outcome of “Action Skipped”. Otherwise they will perform any configured value mapping for those actions that require or support it. This is followed by the execution, which is where a record will be created or updated, or a remote API call is made to complete the action.

When setting up a process, you choose a Source to apply actions to. A source is for example a LogicMonitor event, an alert, or an incident in ServiceNow. Actions have data bindings that map items from the source record into the record created by the action. You can conditionally control what happens when defining the process flow. The logic of an action is prebuilt, so you only have to select how to map the data from the input record.

Actions can be run automatically or manually (interactively) depending on the source. Automatic actions can only be applied to events, machine learning records (ml), and ServiceNow events. You can apply actions to alerts and insights, but not do any automatic processing.

Action Groups

An Action Group is a sequence of individual steps with actions that are executed in order one or more times within the Action Group. Action groups are triggered by different rule types, see About Rules. An example of an action group is “Create Incident(Alert)”. This contains action steps to create an incident in ServiceNow when configured conditions are met.

The following preconfigured Action Groups are available:

• Alert Correlation—Creates and updates insights and incidents in ServiceNow, based on the outcome of machine learning events.
• Alert Processing—Processes incoming events, creates and updates alerts and associated incident in ServiceNow.
• Assign Alert—Process for manually assigning an alert from LM Dexda.
• Assign Insight—Process for manually assigning an insight from LM Dexda.
• CMDB Processing—Stores enrichment data for configuration items.
• Close Alert—Process for manuallly closing an alert from LM Dexda.
• Close Insight—Process for manually closing an insight from LM Dexda.
• Create Incident(Alert)—Creates an alert-based incident in ServiceNow.
• Create Incident(Insight)—Creates an insight-based incident in ServiceNow.
• Incident Processing—Updating of incident details for alerts and insghts in Service Now.
• LM Enrichment Processing—Storing of enrichment data for LogicMonitor events (alerts).
• Link to existing ServiceNow Incident—Creates a reference link for an alert to an incident in ServiceNow.

An Action Group Entry is an Action plus configuration, preconditions, and mappings, that define a set of steps to be executed for a specific process or workflow outcome. Executing one Action Group Entry as part of an Action Message execution, results in an Outcome. This includes records that were updated by that execution, and the values in the records that were updated.

Outcome Types

After an Action Group Entry has completed its execution, there is an outcome of a defined type. Some Outcome types are common to all actions, for example “Action Skipped”, and “Action Failed”. Other Outcome types are more specific to the type of action, for example “Alert exists”, “Alert created”, “Alert updated”, “SNC Incident created”, and “Enrichment data stored”. For more information, see Configuration Parameters in Creating Action Groups.

Mappings

Using “Mappings” your can override and add additional mappings to change the default behavior of the action. You can for example add a mapping to always show the description of the most recent alert instead of the timestamp-based.

For Mapping Fields configuration parameters, see Creating Action Groups.

Mapping Types

Mapping types are different methods for building mappings, for example through text (value), or by selecting from a list of fields (variable) generated from the records in the process sequence. You can for example use the “multi_variable” option to create an associated Work Note in ServiceNow.

For Mapping Types configuration parameters, see Creating Action Groups.

Example

The following is a walk-through of the steps and actions in the preconfigured Alert Processing Action Group.

This is what the corresponding Action Group configuration looks like in LM Dexda.

The source for this process is the flow of incoming events from LogicMonitor. The process is triggered by the arrival of a new event. The sequence has the following steps with these actions:

1. Create a new alert—If the event severity is > 0, and there is no existing open alert, a new alert is created (outcome “alert cleared”).
2. Update existing alert—If the outcome of the previous step is alert exists, and alert is not closed, then the existing alert is updated.
3. Lookup external rowkey—If the outcome of the previous step was update alert, then find the reference to the ServiceNow ticket.
4. Update existing ServiceNow incident—If the outcome of the previous step was “rowkey found”, then update the ServiceNow incident.
5. Wait for correlation—A delay action occurs if the state is new, and the last outcome was ServiceNow incident unknown, or action was skipped. Ensures that only new alerts are correlated. Waits for 15 minutes before continuing, correlation runs in the background.
6. Create a ServiceNow incident—If the last action was completed (waited and alert is still in “new” state), an Insight is created and the alert state is set to “correlated”. If not able to correlate, an incident is created for the (uncorrelated) in ServiceNow. if correlated and not “new”, nothing happens.
7. Store rowkey—The flow for a “new” alert. In a previous step the rowkey was looked up in ServiceNow, and here it is returned. It is stored only if the outcome was that an incident was created. External record type is “sncIncident”, and internal record type is “alerts”.
8. Update Alert—Sets the value of the incident ID to” pending”. Th eprocess requested an incdent creation in ServiceNow, and eventually a ServiceNow record will be returned.
9. Wait for 24 hours—This delay only occurs if the alert was not correlated, and not closed in ServiceNow.
10. Close alert if cleared for > 24 hours—Sets the alert escalation to “closed”, and the alert disappears from the list of Uncorrelated Alerts on the dashboard. This only happens if the alerts hasn’t been touched during the 24 hour period. Note that any associated ServiceNow incident record is still available, and you can access the alert details in LM Dexda from the link in ServiceNow.

For information about configuration parameters, see Creating Action Groups and About Filters.