Event policy types and evaluation order

This topic provides information about the event policy types, the order in which event policies are evaluated, and the out-of-the-box event policy templates.

Event policy types

The following event policy types are available in BMC Helix Operations Management:

• Refinement: Performs conditional enrichment on event slots such as the host.
• Basic Enrichment: Processes events with refined slot values to make the events more meaningful.
• Suppression: Automatically drops new events matching the event selection criteria.
• Advanced Enrichment: Processes events with refined slot values based on advanced settings and the defined policy workflow.
• Dynamic Enrichment: An extension of advanced enrichment, this policy helps you enrich events with external data. 
• Time Based: Processes events with refined slot values after a scheduled duration of time and based on the advanced settings and the defined policy workflow. 
• Correlation: Correlates and combines multiple matching events into a single aggregated event. 
• Notification: Notifies users via email or incidents generated for Proactive Service Integration (PSR) about an event occurrence so that actions can be taken.

Policy evaluation order for processing events

In general, events flow through phases based on certain built-in rules. Each phase represents a logical state of processing.

The event policy types and blackout policies are associated with a particular phase through which the event must flow. These policies process each incoming event one phase at a time, and evaluate each event based on the built-in rules.

Based on the built-in rules, policies are automatically run in the following evaluation order. Events are processed in the same order.

1. Normalize phase
   The normalize phase is a system-defined phase. In this phase, the default values for internal event slots, for example, Modified (_modified_time) and Occurred (creation_time) are set. This phase also validates the event slots and the event class name. If the slots do not confirm to the event schema, they are listed as unmapped data in the event. If the class name is invalid, the Event-base-event-class is considered as the default class for the event. 
2. Refinement policy
   Use the refinement policy to enrich event topology slots such as the Host (source_hostname). This event policy phase allows you to perform limited advanced event enrichment and dynamic event enrichment. Advanced event enrichment in this phase is limited to using the If, Enrich, and Variable actions. For more information about these actions, see Actions-for-advanced-and-time-based-enrichment.
3. Topology enrichment
   Topology enrichment is a system-defined phase. In this phase, the Service ID (service_id) and Node ID (_node_id) details (entity details) are looked up from BMC Discovery according to the topology lookup slots in the event class. For example, the source_hostname slot for the Event class. These slots are attributes of service models in BMC Helix AIOps. Based on the topology lookup slots, the system uses BMC Discovery APIs to fetch the node details and enriches them in the event. The API query retrieves the node details by using the AND or OR operators in the query conditions and associates multiple nodes to an event. 
   Consider populating the cdmclass slot in the event with the specific node kind that is present in BMC Discovery. This process makes the node lookup quicker because only specific node kinds are associated with the event instead of all possible nodes. 
   To learn more about topology enrichment, see the following topics:
   
   • Slot-facets
   • Event-enrichment-for-adding-context
     To learn how to retrieve CI attributes, see the LookupNodeDetails function.
4. Basic enrichment policy
   Use the basic enrichment policy to quickly enrich popular event slots such as Severity, Priority, Category, Location, and Message. 
5. Out-of-the-box suppression policies and configurable suppression policies
   The system executes the out-the-box suppression policies internally. For more information, see Out-of-the-box-event-policies-and-templates.
   Use the suppression policy to suppress unnecessary events and reduce event noise. For more information, see Event-deduplication-and-suppression-for-filtering-unwanted-events. 
6. Blackout policy
   Incoming events are blacked out based on the conditions configured in the blackout policy. Blackout policies have a different workflow than event policies.
   For more information, see Blackout-policies.
7. Time-based enrichment policy
   Use the time-based enrichment policy to process events after a specific duration. For an event, only one time-based policy is applied.
   For more information, see Advanced-time-based-and-dynamic-enrichment-policies.
8. Advanced enrichment policy and dynamic enrichment policy (these policies are evaluated in the order of creation)
   Use the advanced enrichment policy to enrich events and add additional context to events to help operators resolve events efficiently. For more information, see Building-a-policy-workflow-for-advanced-and-time-based-enrichment.
   Use the dynamic enrichment policy to enrich events with external data. For more information, see Dynamically-enriching-events-with-external-data.
9. Correlation policy
   Use the correlation policy to group related events, detect event patterns, and reduce event storms. For more information, see Event-correlation-for-aggregating-related-events.
10. Notification policy
    Use the notification policy to send email notifications and generate incidents in BMC Helix IT Service Management to notify operators about important issues or changes. For more information, see Event-based-notifications-for-alerting-users.

Multiple configurations in a single event policy execute as independent policies according to the preceding policy phases. For each configuration in the policy, the event selection criteria is checked to process incoming events. If a previously executed policy phase changes the state of an event, then the updated event state is considered for the execution of the next policy phase.

The policy evaluation order supersedes the precedence number specified in the various types of policies. This means, even if you configure a separate event policy for each of the types with varying precedence numbers, the policy evaluation order is used to run the policies.

However, if you have configured the following precedence numbers in event policies, then these conditions apply:

• Multiple event policies of different types with varying precedence numbers, then policies of the same type are run based on the precedence number specified. 
• Multiple event policies of different types with the same precedence numbers, then the policies are run according to the policy evaluation order to process events.
• Multiple event policies of the same type with the same precedence numbers, then the policy that was last modified is run to process events.

Example scenarios

Where to go from here

To create, edit, enable, disable, or delete an event policy, see Defining-event-policies-for-enrichment-correlation-notification-and-suppression.

To understand advanced, time-based, and dynamic enrichment policies, see Advanced-time-based-and-dynamic-enrichment-policies.

To understand refinement policies, see Event-enrichment-through-refinement-policies.

To understand the out-of-the-box event classes and associated slots, see Event-classification-and-formatting.