ServiceNow integration

ServiceNow integration is an optional layer for organizations that want monitoring events to participate in ITOM Event Management, CMDB-aware correlation, incident management, and operational workflows. It is not embedded in a core Management Pack or Azure Monitor health model.

Current status

The SCOM-to-ServiceNow configuration baseline is implemented and passes offline validation. It has not yet been installed or certified against a live ServiceNow/SCOM/MID Server environment. The Azure Monitor-to-ServiceNow path remains design and research work.

For the implemented SCOM path, continue to the SCOM-to-ServiceNow integration guide.

What exists and what remains

ServiceNow already provides the SCOM (Events) connector. The first integration does not require a new custom connector or changes inside either sealed Management Pack.

Capability	Owner	Status
SCOM Events connector	ServiceNow product	Existing vendor connector; requires ITOM Event Management and a Windows MID Server
Azure Local connector profile	This repository	Implemented; explicit `HybridSolutionsCloud.AzureLocal.*` allow-list
Hyper-V connector profile	This repository	Implemented separately; explicit `HybridSolutionsCloud.HyperV.*` allow-list
Event identity, severity, and lifecycle mapping	This repository	Implemented as a versioned, secret-free contract
Offline contract validator	This repository	Implemented; builds both MP suites and validates profiles, mappings, alert lifecycle, and secret policy
MID Server, SCOM client assemblies, credentials, CI binding, and connector instance	Customer lab	Must be configured in the new environment
Live fault, recovery, replay, maintenance, and optional write-back proof	Customer lab	Not yet executed
Automated ServiceNow deployment	Future decision	Intentionally deferred until the installed connector release and fields are proven in the lab
Azure Monitor-to-ServiceNow delivery	Future implementation	Secure Webhook/common-alert-schema design selected; mapping and deployment artifacts not yet authored

A custom SCOM connector should be considered only if the installed ServiceNow connector cannot support the approved SCOM release, allow-list, identity, or lifecycle requirements. That decision requires a new ADR and lab evidence; it is not the default plan.

Solution boundaries

Monitoring solution	ServiceNow delivery boundary
Azure Local SCOM MP	Development connector profile, namespace allow-list, mappings, validation, and operator guidance
Hyper-V SCOM MP	Separate development profile, allow-list, mappings, and tests targeting Hyper-V classes and alerts
Azure Local Azure Monitor	Optional action-group, webhook, mapping, and deployment guidance
Hyper-V Azure Monitor	Reserved until the parent Azure Monitor solution receives a go decision

There is no shared ServiceNow runtime package that makes one solution depend on another. A common event-field contract may be documented and tested across solutions.

SCOM architecture

The implemented boundary uses the ServiceNow SCOM Events connector running through a Windows MID Server. It collects SCOM alerts and can synchronize supported close, reopen, acknowledgement, and ticket-reference behavior. The separate SCOM Metrics connector is evaluated only when ServiceNow Metric Intelligence is licensed and metric ingestion provides demonstrated value.

Rendering diagram…

The Management Packs remain connector-neutral. Their responsibility is to provide stable object identity, actionable alerts, consistent severity, complete context, predictable auto-resolution, and documented maintenance behavior. Credentials, MID Server configuration, ServiceNow mappings, and incident policy stay outside the sealed MPs.

Azure Monitor planned architecture

The preferred candidate is an Azure Monitor action group using a Secure Webhook with the common alert schema to the ServiceNow Event Management endpoint. Direct integration is preferred when standard field mapping is sufficient. Azure Logic Apps is evaluated when the workflow needs CMDB lookups, routing, payload enrichment, approval, retry queues, or multiple destinations.

Rendering diagram…

New development will not target legacy Azure Monitor ITSM actions. Microsoft directs existing ServiceNow ITSM-action integrations toward Secure Webhook actions. Basic-authentication webhook URLs are not the preferred production design; authentication must use the least-privileged supported OAuth or Secure Webhook pattern.

Dual-source authority

An environment may run SCOM and Azure Monitor at the same time. Sending equivalent conditions from both tools directly to ServiceNow can create duplicate events, alerts, and incidents.

Each deployment must choose one of these policies:

SCOM authoritative — SCOM sends the condition; Azure Monitor remains informational.
Azure Monitor authoritative — Azure Monitor sends the condition; SCOM remains operationally visible but does not forward the equivalent alert.
ServiceNow correlation — both sources send events only after a proof demonstrates reliable CI binding and a stable correlation key.

A candidate correlation contract includes platform, solution, environment, stable entity identity, condition or monitor identity, and lifecycle state. Display names and alert text are not stable keys.

Research and decision gates

Workstream	Evidence required
Product and licensing	Supported SCOM, Azure Monitor, ServiceNow release, ITOM/Event Management, Metric Intelligence, and IntegrationHub requirements
Connectivity	MID Server placement, firewall paths, proxies, private ServiceNow constraints, Azure endpoints, and failover behavior
Identity and security	Least privilege, OAuth/service principal roles, credential storage, rotation, audit logs, and no secrets in source
Data contract	Alert/event fields, entity and CI keys, severity, priority, ownership, knowledge links, health state, and custom properties
Lifecycle	Open, update, acknowledge, assign, suppress, maintain, resolve, reopen, close, and stale-connector behavior
Noise control	Allow-listing, flapping, deduplication, correlation, root-cause versus symptom policy, and rate limits
Reliability	Retry, dead-letter handling, outage recovery, replay safety, connector monitoring, and service-level targets
Operations	Runbooks, dashboards, tests, troubleshooting, upgrade, rollback, and removal

Proof-of-concept acceptance

The proof must demonstrate:

one SCOM alert and one Azure Monitor alert opening with correct CI, severity, owner, and context;
repeated observations updating rather than duplicating the ServiceNow alert;
source recovery closing or resolving the correct record;
maintenance and suppression preventing unwanted incidents;
a ServiceNow or connector outage recovering without silent loss or uncontrolled replay;
bidirectional behavior, if enabled, changing only the intended source alert;
dual-source tests producing one operational incident for one underlying condition; and
complete audit evidence with no credential material in logs or repository artifacts.

Delivery status

supported integration and licensing matrix — research baseline complete; installed-release and SCOM 2025 confirmation remain;
SCOM event, alert, CI, severity, and lifecycle mapping — development contract complete;
Azure Monitor common-alert-schema mapping — not started;
authoritative-source and correlation decision record — required before dual-source deployment;
security and connectivity design — SCOM baseline documented; Azure Monitor detail pending;
repeatable lab fixtures and fault tests — offline contract complete; live fixtures remain;
optional configuration profiles owned by each source solution — development baseline complete;
administrator, troubleshooting, upgrade, and rollback documentation — SCOM guide complete;
Azure Monitor integration implementation — later.

ServiceNow integration ​

What exists and what remains ​

Solution boundaries ​

SCOM architecture ​

Azure Monitor planned architecture ​

Dual-source authority ​

Research and decision gates ​

Proof-of-concept acceptance ​

Delivery status ​

Current references ​