CIS-EM Study Guide (Certified Implementation Specialist, Event Management)

Trademark disclaimer: ServiceNow, the ServiceNow logo, Event Management, Health Log Analytics, Operational Intelligence, Service Operations Workspace, and related product names are trademarks of ServiceNow, Inc. This is an independent, original study guide written for exam preparation. It is not affiliated with, endorsed by, or sponsored by ServiceNow, Inc. All product behavior should be verified against official ServiceNow product documentation for your instance release.

This guide is ordered by exam weight. The two heaviest domains (Event Configuration and Use at 34%, Alerts and Tasks at 30%) come first and account for roughly two-thirds of the scored items. Study them deeply; treat the remaining domains as supporting context that the configuration questions assume you already know.

Domain 3: Event Configuration and Use (34%)

This is the largest domain on the exam. It is about what happens to an event after it lands in the instance and before a human ever sees it: how events are normalized, filtered, matched, transformed, thresholded, deduplicated, and ultimately bound to a configuration item (CI) and turned into an alert.

Events versus alerts (the foundational distinction)

An event is a single, raw, machine-generated notification that something happened on a monitored resource, such as a CPU spike, a service stopping, a disk filling. Events are noisy and high-volume. They are stored in the Event [em_event] table. An event by itself does not demand action; it is data.

An alert is the actionable, deduplicated, human-facing record that Event Management produces from one or more events. Alerts live in the Alert [em_alert] table. Many events typically collapse into a single alert. The whole point of Event Management is this reduction: turn a flood of events into a small number of meaningful, prioritized, CI-bound alerts that an operator or automation can act on.

A useful mental model: events are the input signal; alerts are the curated output. Event rules are the machinery in between.

The event-to-alert processing flow

When you can recite this pipeline in order, most configuration questions become answerable. The high-level flow:

Event ingestion: events arrive (push via web service/REST, or pull via a MID Server connector) and are inserted into em_event with state Ready.
Event rule evaluation: the processing job evaluates event rules against each event. Rules can filter (ignore), transform/normalize field values, set severity, compose the message key, and define how the resulting alert binds to a CI. Event field mappings (a separate Event Field Mapping [em_mapping_rule] table) then translate values such as vendor severities; they apply after event rule processing and before alert generation, even when no event rule matched.
Threshold checks: optional thresholds can suppress alert creation until a number of matching events occur within a window (reduces flapping/noise).
Alert creation or update: events sharing the same message key are deduplicated onto the same alert. The first matching event opens the alert; subsequent matching events increment the event count and update the alert rather than creating new alerts.
CI binding: the alert is associated to a CI in the CMDB so impact and correlation can be calculated.
Downstream processing: alert correlation, aggregation, alert management/remediation rules, and (optionally) incident creation.

Event processing states you should know are Ready (received and waiting to be processed), Processed (successfully processed), and Error (processing failed, for example because the event severity is blank). The State choice Ignored exists but is documented as not in use: an event dropped by an event rule's ignore filter is still recorded in em_event, and its Processing Notes show which rules were applied.

The message key: the heart of deduplication

The message key is the identity fingerprint of an alert. Event Management builds a message key for each event (by default from a combination of fields such as source, node, type, resource, and metric name, but you control it in event rules). All events that produce the same message key are treated as the same problem and roll up to one alert.

This is the single most important configuration concept in the domain. Get the message key too broad and unrelated problems collapse into one alert (loss of fidelity). Get it too narrow and one real problem fragments into many alerts (noise returns). Tuning the message key is the lever that controls deduplication granularity.

Event rules: the core configuration object

An event rule processes events that match its filter and applies actions. Event rules are evaluated in ascending Order; lower order runs first. By default only the first matching rule is applied; selecting Apply additional matching rules lets later matching rules run as well. A well-designed rule set runs cheap, specific filters early.

An event rule has these functional parts:

Filter / event matching: the conditions that decide whether this rule applies to a given event (for example, source equals "SCOM" and the description contains a pattern). If the event does not match, the rule is skipped.
Transform and compose: map and normalize raw vendor fields into the standard Event Management fields. You can use regular expressions to extract substrings from the raw text, JavaScript for richer logic, and templates to compose values. Common targets: type, resource, metric_name, severity, node, and the message key itself.
Threshold: optionally require N matching events within a time window before an alert is generated, suppressing transient blips.
CI binding / additional information: specify how the resulting alert binds to a CI, and add supplementary fields.
Ignore: on the Event Filter tab, Ignore events that match this filter stops matching events from creating alerts while the events stay recorded in em_event (a clean way to drop known-benign noise).

A practical note that frequently appears as a distractor: an event rule that does not bind a CI does not stop alert creation; the alert can still be created but may be unbound (or bound by fallback logic).

Binding events/alerts to CIs (CI binding)

CI binding is what makes Event Management service-aware. An alert bound to a CI can be placed on a service map, correlated with topologically related alerts, and used to compute service impact.

Binding strategies, in rough order of reliability:

Direct CI match: the event carries a value (such as cmdb_ci sys_id, name, FQDN, or IP) that maps to exactly one CI. The event rule's binding configuration names which event field maps to which CI identifier.
Binding rules / additional binding logic: when a single field is not enough, additional binding logic resolves the correct CI, often using the node plus another attribute.
No match: if no CI is found, the alert may remain unbound; unbound alerts still appear but cannot participate in topology-based correlation or service impact.

Know the difference between binding to a CI versus simply storing a node name string: only a resolved CI reference participates in CMDB-driven correlation and impact.

Thresholds

A threshold suppresses alert generation until a configured count of matching events is reached within a configured interval. Thresholds are how you tame flapping (a resource that rapidly oscillates between healthy and unhealthy). They live as part of event-rule configuration. The exam may test the difference between a threshold (count over time gates alert creation) and deduplication (message key collapses many events into one existing alert).

Tools for configuration and validation

Regular expressions are used inside event rules to parse and extract values from unstructured event text.
JavaScript is available for transform logic that is too complex for a simple regex or field map.
PowerShell appears on the collection side for Windows-based connectors (for example, pulling from SCOM).
Event simulation / test: you can simulate event processing to see which rule matches, what the transformed event looks like, and what alert (and message key) results, without waiting for live data. This is the recommended way to validate rule logic before deploying.
Event processing statistics let you monitor throughput, backlog, and error rates of the processing job.

Operator-facing use

Operators consume alerts in Service Operations Workspace (the current workspace experience) and through alert/console views. The older Operator Workspace is deprecated from the Vancouver release onward and remains only for customers who upgraded from a release before Utah. The configuration you do upstream (good message keys, correct CI binding, sensible severity normalization) is what makes the operator view usable.

Domain 4: Alerts and Tasks (30%)

The second-heaviest domain. If Domain 3 is "how an alert is born," Domain 4 is "what happens to the alert for the rest of its life": correlation, aggregation, prioritization, remediation, task/incident creation, and closure.

The alert record and its lifecycle

An alert moves through states. The canonical ones are Open (active, needs attention), Reopen (was closed but a new matching event arrived), Flapping (oscillating), and Closed (no further action required). A key behavior: when the underlying condition clears, a resolution (clear) event can automatically close the alert, and a later recurrence can reopen it. Operators can also manually acknowledge, close, or assign alerts.

Important alert fields include severity (Critical, Major, Minor, Warning, Info / Clear), state, the bound CI, the source, the message key, event count, and the computed alert priority score used for ranking.

An alert closes manually, automatically when a closing event arrives on the same message key (Clear severity, or a resolution state of Closing), or when its related incident is resolved (property evt_mgmt.incident_closes_alert). Closing an alert also closes a related incident that is not already resolved or closed (property evt_mgmt.alert_closes_incident). There is no "Resolved" alert state.

Alert severity and priority

Event Management normalizes vendor severities into a standard numeric scale: 1 Critical, 2 Major, 3 Minor, 4 Warning, 5 Info (shown as OK on events), plus 0 Clear, which closes the matching alert. For active problems a lower number means higher urgency, so Critical (1) is the most urgent. An alert's severity is copied from each incoming event for its message key; when the event closes the alert, the previous severity is kept for reporting. Operators triage by severity, but the system also computes an alert priority score, a weighted composite led by the number of impacted services factored by their business criticality, then severity, CI type, alert role (primary, secondary or none), the number of secondary alerts, and state. The category order and weights are configurable. Service-aware scoring is what lets an operator focus on the alert that actually threatens a critical service rather than the loudest alert.

Alert correlation rules

Alert correlation reduces the number of alerts an operator must look at by establishing primary/secondary (parent/child) relationships between alerts that are part of the same underlying problem. The operator then works the primary alert; the secondaries are suppressed under it.

Correlation can be driven by:

CMDB / topology-based correlation: alerts on CIs that are related in the CMDB (for example, a host and the application running on it) are grouped, often with the upstream/root CI's alert designated primary. For CIs without historical learning data, the system falls back to CMDB relationships.
Alert correlation rules: explicitly authored rules that define which alerts correlate and which becomes primary.
Automated alert grouping (machine learning): the Alert Aggregation Learner studies historical alerts and groups alerts that frequently occur together, producing automated alert groups even when alerts are not identical. It needs alert history, so groupings are weak right after go-live.

When a primary alert is closed, its secondary alerts are also closed by default; for manual and rule-based groups the property evt_mgmt.rule_based_manual_closure can keep them open instead.

Alert aggregation

Alert aggregation groups related alerts to support root-cause analysis. Where correlation produces primary/secondary pairs, aggregation forms broader alert groups (including CMDB alert groups and automated alert groups) that represent one underlying event or incident. The goal is the same throughout the domain: fewer things for a human to look at, with the likely root cause surfaced.

Alert management rules (resolving and acting on alerts)

Alert management rules (the Alert Rules Management application, sn_em_arm) are automation that fires when an updated, open alert matches the rule's filter; they do not run on closed alerts. They can:

Run subflows, including base-system subflows such as Create Incident, Close Alert, Acknowledge Alert, and Change Alert to Maintenance Mode.
Trigger remediation: launch a remediation subflow or workflow automatically, or let an operator run it manually.
Create and link records: generate incidents, tasks, or knowledge articles for alerts that meet the filter.
Launch applications or URLs built from alert field values.

Closing an alert on a clear event is native event processing, not an alert management rule. Legacy alert action rules from earlier releases must be migrated to alert management rules before they can be modified. Alert management rules are evaluated in ascending Order (default 100) by a scheduled job that runs every 11 seconds by default, so specificity and sequencing matter just as with event rules.

Remediation (subflows and Flow Designer)

Remediation is the bridge from detection to automated resolution. Event Management ships base-system subflows (built in Flow Designer) for common alert handling: Create Incident, Close Alert, Acknowledge Alert, Change Alert to Maintenance Mode, and major incident variants. Fixes such as restarting a service or gathering diagnostic data are built as custom subflows (or Orchestration workflows; subflows are recommended for performance). You configure alert remediation actions so an operator (or an automatic rule) can launch a remediation subflow directly from the alert.

Two modes to distinguish:

Manual / on-demand remediation: the operator clicks a remediation action on the alert; the subflow runs and the outcome is recorded back on the alert.
Automatic remediation: an alert management rule launches the subflow without human intervention when conditions are met.

You build custom remediation in Flow Designer as a subflow (so it can accept the alert as input and be reused) rather than as a one-off flow.

Tasks and incident creation

Event Management can create incidents (and other tasks) from alerts. This is governed by an alert management rule that runs the Create Incident subflow (or, in Service Operations Workspace, a Create incidents alert automation) and decides which alerts warrant a task and how the task is populated from alert fields. The Create Incident subflow does not run for alerts in maintenance or alerts that already have an incident. The alert and the resulting incident stay linked so that closing one can reflect on the other (properties evt_mgmt.alert_closes_incident and evt_mgmt.incident_closes_alert). The exam expects you to know that incident creation is configurable and conditional, not automatic for every alert.

Scheduled jobs

Several background scheduled jobs drive alert lifecycle behavior: processing events, evaluating correlation, closing stale alerts, and recomputing scores. Knowing that these are scheduled jobs (and that delays in alert behavior can trace back to job timing) is fair game.

Domain 1: Event Management Overview (13%)

This domain sets positioning and vocabulary.

What Event Management is and where it fits

Event Management is part of ITOM (IT Operations Management), ServiceNow's suite for managing infrastructure and services. ITOM's pillars include Discovery and Service Mapping (populate and relate the CMDB), Event Management (turn monitoring noise into actionable alerts), Operational Intelligence / Metric Intelligence (anomaly detection on metrics), Health Log Analytics (anomaly detection on logs), and Cloud/Service operations. Together with machine learning these form ServiceNow's AIOps story.

The customer problem Event Management solves: enterprises run many monitoring tools (SCOM, SolarWinds, Nagios, Zabbix, cloud-native monitors), each generating its own alerts in its own silo. There is no single, prioritized, service-aware view. Event Management consolidates events from all of these into one place, deduplicates and correlates them, binds them to the CMDB, and computes business impact, so operators act on what matters.

Core value concepts

Noise reduction: many events to few alerts, via message keys, thresholds, correlation, and aggregation.
Service awareness: alerts bound to CIs and rolled up to the services they support, so impact is visible.
Proactivity: Operational Intelligence and Health Log Analytics surface anomalies before a hard threshold breach or outage.
Closed-loop remediation: from alert to automated fix via Flow Designer subflows.
CSDM alignment: Event Management relies on a CMDB structured per the Common Service Data Model so that service impact and reporting are meaningful.

Dashboards and visibility

Operators and managers consume Event Management through Service Operations Workspace, alert consoles, application service maps (showing active alerts on CIs and their relationships), and dashboards/Performance Analytics for trends. The dashboards answer "what is broken, what does it affect, and is it getting better."

Domain 2: Architecture and Discovery (13%)

This domain is about the moving parts that make Event Management work and how it depends on a well-discovered CMDB.

MID Server

The MID Server (Management, Instrumentation, and Discovery) is a Java application that runs inside the customer network and brokers communication between the ServiceNow instance and on-premise resources. It is the workhorse for both Discovery and Event Management collection. The instance never connects directly into the customer's data center; the MID Server does, and it initiates outbound communication to the instance.

For Event Management, a MID Server runs connectors that collect events. MID Servers have capabilities and applications that scope what work they can do; for Operational Intelligence/metrics you assign the Metrics capability and run the Operational Intelligence (Metric Intelligence) extension. MID Servers can be clustered for load balancing and high availability.

Discovery and the CMDB dependency

Event Management is only as service-aware as the CMDB beneath it. Discovery populates the CMDB with CIs and their attributes; Service Mapping builds the service topology (application services: which CIs support which service). Zurich impact calculation runs for Service Instance [cmdb_ci_service_auto] classes such as application services, not for Business Service or Technology Management Service records. Without accurate CI records and relationships, CI binding fails, topology-based correlation cannot work, and service impact cannot be computed. This is why CMDB health, CSDM structure, and Discovery quality are explicitly part of Event Management architecture.

How events reach the instance

Push: an external monitor (or script) sends events to the instance or to a MID Server via the web service / REST API. The sender initiates.
Pull: a MID Server connector periodically queries the external monitoring system and brings events back. The MID Server initiates on a schedule.

Both paths land events in em_event for the same processing pipeline.

Components installed

Activating Event Management installs the event/alert tables, processing jobs, base event rules and subflows, dashboards, and the operator workspace artifacts. Operational Intelligence and Health Log Analytics are separately installed/licensed capabilities layered on top.

Domain 5: Event Sources (10%)

The smallest domain: how specific monitoring tools feed Event Management.

Connectors and connector instances

A connector definition is the template describing how to talk to a given source type; a connector instance is a configured copy pointing at a specific server with its credentials and schedule. Connector instances run on a MID Server. ServiceNow ships connector definitions for common monitors, and you can build custom ones.

Representative sources

Microsoft SCOM (System Center Operations Manager): a pull connector instance collects alerts/events from SCOM, typically using PowerShell on the MID Server's Windows host. SCOM has both an event connector and a separate metric connector for Operational Intelligence.
SolarWinds: a connector instance collects events from the SolarWinds monitor; configured with the SolarWinds host, credentials, and polling schedule.
Other supported sources: Nagios, Zabbix, SCOM, SolarWinds, and many more, plus generic REST/web service ingestion for anything without a packaged connector, and email-based event ingestion in some cases.
SNMP traps: the SNMP trap collector is a MID Server extension that listens for traps and sends them to the instance, where Event Management processes them as events. Syslog arriving through a MID Server is a Health Log Analytics data input (for example Rsyslog), not an Event Management event listener.
Push through a MID Server: the MID Web Server extension lets a MID Server accept events pushed over REST from tools that cannot reach the instance and forward them to the instance.

Operational Intelligence / Metric Intelligence (metric-based sources)

Beyond discrete events, Event Management ingests metrics (time-series data such as CPU, memory, latency). The MID Server's Operational Intelligence extension pulls raw metrics, the platform learns each metric's normal bound/baseline, and anomaly detection flags deviations. Anomalies are scored 0 to 10, mapped onto the five severity levels and visualized in the Metric Explorer and Anomaly Map. Anomalies can generate alerts just like events, enabling detection before a static threshold is crossed.

Health Log Analytics (log-based sources)

Health Log Analytics (HLA) ingests machine-generated log data in real time, learns normal log patterns, and detects anomalous log behavior (new error signatures, sudden volume spikes). HLA triages related issues, helps identify root cause, and can generate alerts that flow into the same Event Management alert lifecycle, extending AIOps coverage from metrics and events to logs.

Fast-recall cheat list

Event = raw single notification (em_event); Alert = deduplicated actionable record (em_alert). Many events to one alert.
Message key = the alert's identity fingerprint; same message key to same alert (deduplication). Too broad = collapsed unrelated problems; too narrow = noise.
Pipeline: ingest to event rules (filter/transform/threshold/bind) to event field mappings to dedupe by message key to alert create/update to correlation/aggregation to remediation/incident.
Event states: Ready, Processed, Error (the Ignored choice is not in use; events dropped by an ignore filter are still recorded in em_event).
Event rules run in order; can filter, transform (regex/JavaScript), set severity, build message key, bind CI, set threshold, or ignore.
Threshold gates alert creation by count-over-time (anti-flapping); dedupe collapses events onto an existing alert.
CI binding makes alerts service-aware; unbound alerts cannot do topology correlation or service impact.
Severity: 1 Critical, 2 Major, 3 Minor, 4 Warning, 5 Info (OK), 0 Clear. Lower number = more urgent; alert severity follows the latest event.
Correlation = primary/secondary (parent/child) grouping; aggregation = broader alert groups for root cause. CMDB/topology, authored rules, and ML automated alert grouping all drive grouping. Closing a primary closes its secondaries by default.
Alert management rules (ascending Order, open alerts only): run subflows (Create Incident, Close Alert, Acknowledge Alert), trigger remediation, create incidents/tasks/knowledge articles, launch URLs. Alert action rules are legacy.
Remediation = Flow Designer subflows (base-provided + custom); manual (operator click) or automatic (rule-triggered).
Incident creation from alerts is conditional/configurable, not automatic for all alerts.
MID Server brokers instance to on-prem; outbound-initiated; runs connectors; needs Metrics capability + OI extension for metrics.
Push = sender to instance/MID via REST/web service; Pull = MID connector queries source on schedule.
Connector definition = template; connector instance = configured pointer to a specific server.
Sources: SCOM (PowerShell pull; separate event vs metric connectors), SolarWinds, Nagios, Zabbix, REST.
Operational Intelligence / Metric Intelligence: anomaly detection on metrics; score 0 to 10; Metric Explorer + Anomaly Map; detects before static threshold.
Health Log Analytics (HLA): anomaly detection on logs; generates alerts into the same lifecycle.
ITOM context: Discovery + Service Mapping feed CMDB; CSDM structure required for accurate impact; this is AIOps.
Operator surface: Service Operations Workspace, alert console, application service maps, dashboards/Performance Analytics.
Alert priority score: weighted by impacted service business criticality, then severity, CI type, role, number of secondary alerts, state.