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 — 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 bind the event to a CI.
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 states you should know include Ready (waiting to be processed), Processed (successfully handled), Error (could not be processed, often a malformed field or failed binding), and Ignored (matched a rule that discarded it).

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 order (each has an order/sequence value); lower order runs first. 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 — a rule can simply mark matching events as Ignored so they never become alerts (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 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 (resolved). 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 priority/secondary score used for ranking.

Alert severity and priority

Event Management normalizes vendor severities into a standard scale. Severity 0 = Clear, and higher numbers escalate through Info, Warning, Minor, Major, to Critical (the highest actionable). Operators triage by severity, but the system also computes a priority/secondary alert score that blends severity with business impact (for example, how many services or how critical a service the CI supports). Service-aware scoring is what lets an operator focus on the alert that actually threatens a revenue-bearing 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.
Service Analytics / machine-learning correlation — Operational Intelligence learns patterns and groups alerts that frequently occur together, producing correlated alert groups even when alerts are not identical.

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 Service Analytics correlated 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 are automation that fires when an alert matches a condition. They can:

Resolve/close alerts automatically (for example, auto-close low-severity alerts after a window, or close on receipt of a clear event).
Group or transform alerts.
Trigger remediation — invoke a remediation subflow or create a task.
Create tasks/incidents — open an incident (or other task) for alerts that meet a threshold of severity or impact.

These rules also run in order and have conditions, 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) that perform common fixes — restart a service, clear a queue, run a diagnostic. 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 configuration (often an alert management rule or a dedicated setting) that decides which alerts warrant a task, how the task is populated (CI, short description, severity-to-priority mapping), and how the alert and the resulting incident stay linked so that closing one can reflect on the other. 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 business services, 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, business 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 (which CIs support which business services). 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.

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–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 dedupe by message key to alert create/update to correlation/aggregation to remediation/incident.
Event states: Ready, Processed, Error, Ignored.
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: 0 = Clear; ascending through Info, Warning, Minor, Major, Critical.
Correlation = primary/secondary (parent/child) grouping; aggregation = broader alert groups for root cause. CMDB/topology, authored rules, and Service Analytics ML all drive grouping.
Alert management rules run in order: auto-resolve, group, create task/incident, trigger remediation.
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–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, business service maps, dashboards/Performance Analytics.