Event Management process flow

  • Release version: Yokohama
  • Updated January 30, 2025
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Event Management process flow

    Event Management in ServiceNow collects, analyzes, and converts incoming events into actionable alerts to enable efficient tracking and remediation of issues. Events originate from external sources via email servers, scripts, SNMP traps, or web service APIs and are processed through the MID Server, which polls external tools and forwards event data to the ServiceNow instance.

    Show full answer Show less

    Events are stored in the Event [emevent] table, where they undergo evaluation against predefined event and alert management rules to determine if alerts should be generated. All events remain available for review and remediation, regardless of alert generation.

    Event to Alert Processing

    • Match Event Rule: The system identifies the best matching event rule based on event source, optional filters, and additional information. Rules without required filters are ignored. Rule order dictates processing sequence when multiple rules apply.
    • Ignore Rule: If an event rule is marked to ignore, no alert is created, but the event is still retained for review.
    • Apply Transforms: Defined transforms and additional compose parameters are applied to enrich alert content.
    • Threshold Accumulation: When enabled, multiple events accumulate until a threshold is reached, triggering a single consolidated alert.
    • Event Field Mapping: Even without a matching event rule, field mappings are applied to structure event data. Events without severity after transformation are retained without alert generation.
    • Alert Generation: The system searches the Alert [emalert] table for existing alerts with matching message keys to update or associates events under a single alert. Alerts are linked to specific Configuration Items (CIs) to support root cause analysis.

    Key Outcomes

    • Automated conversion of raw events into actionable alerts for efficient incident management.
    • Consolidation of related events into single alerts based on thresholds and matching keys reduces noise.
    • Retention of all events ensures complete visibility and auditability, even when alerts are not generated.
    • Binding alerts to Configuration Items enhances root cause analysis and remediation efforts.

    Event Management collects, analyzes, and converts events into alerts, enabling efficient tracking and remediation.

    Event Management receives external events and generates alerts based on event and alert management rules. Events are sent directly to your instance via email server, script, SNMP trap, or web service API. The corresponding alerts appear on dashboards for tracking and remediation purposes.

    As the computer, software, or service generates events, the MID Server polls the external event tracking tool. The MID Server, maintaining a connection to Event Management, sends the information to your instance for storage, processing, and remediation.

    The instance stores events in the Event [em_event] table and attempts to generate alerts based on predefined rules and event mappings. Regardless of whether an alert is generated, the original event is available for review and remediation. Alerts are generated according to the following process flow.

    1. Match Event Rule: Find the best matching event rule for an event.

      A rule is matched if the source of the event matches the source specified in an existing rule. Additionally, a rule is matched if the event matches the optional rule filter and the event additional_info value matches the rule Additional Information filter. A rule without any filter is ignored, such as when the source filter or Additional Information filter is missing. If multiple rules are defined for the same type of event, use the rule order to determine the sequence of rule application.

    2. Ignore Rule: If the rule Ignore check box is selected, no alert is generated. However, the event is still available for review and remediation.
    3. Apply Transforms:
      • If transforms have been defined, apply them.
      • If compose parameters are set, apply the additional content to display to the user in the alert.
    4. Threshold Accumulation: If Active in the threshold section is selected, accumulate all events until the threshold is met, then generate a single alert for the events.
    5. Event Field Mapping
      • Search for an event field mapping even if there was no event rule.
      • If an event field mapping is found, apply the mapping information.
      • If the event has no severity after the event transformations, retain the event for reference purposes and do not generate an alert.
    6. Alert Generation
      • Search the Alert [em_alert] table for a matching message key.
      • If a matching message key exists, update the alert according to the event information.
      • If a matching message key does not exist, create an alert.
      • If another event has the same matching key, associate the events under a single alert.
      • For root cause analysis purposes, bind the alert to a specific Configuration Item (CI).
    Figure 1. Event workflow
    Event workflow