Monitoring-to-ITSM Integration: Designing the OpenText OBM–ServiceNow Event Flow Without Alert Storms

Last updated: November 2026

A good OpenText Operations Bridge Manager (OBM) to ServiceNow integration does not turn every event into an incident. It filters and correlates events in OBM first, creates a ServiceNow incident only for actionable, de-duplicated events, binds each incident to the right CMDB configuration item, and closes or updates the OBM event when the incident is resolved. Designing these patterns up front is what prevents alert storms and duplicate incidents, whichever middleware you use to connect the two systems, from custom scripts to ZigiOps, the no-code integration platform by ZigiWave.

Monitoring-to-ITSM integration looks simple on a whiteboard: an alert fires, a ticket appears. In production, a single network outage can generate hundreds of events, and if each one opens an incident the service desk drowns. This guide is a catalogue of design patterns for automatic incident creation from OBM events into ServiceNow ITSM. It focuses on decisions rather than clicks, so it applies whether you use a native connector, custom scripts or a third-party integration platform as the middleware for ServiceNow integration. Where it helps, the guide shows how a pattern looks in ZigiOps, which has ready-made OBM and ServiceNow connectors.

Why the OBM to ServiceNow flow needs design, not just a connector

OBM is an event consolidation and correlation layer. It receives events from monitoring tools, agents and other sources, relates them to configuration items in its Run-time Service Model (RTSM), and applies correlation rules to identify the cause. ServiceNow ITSM is where incidents are assigned, worked and reported against SLAs. The integration sits between two different worlds:

• Events are high-volume and short-lived. Many are informational or self-resolving.
• Incidents are low-volume and expensive. Each one consumes a person's time, an SLA clock and a line in management reports.

The job of the integration is to translate a stream of signals into a small number of meaningful work items. If that translation is not designed deliberately, you either flood the service desk or miss the events that matter.

The event flow in five stages

It helps to describe the flow as numbered stages. Each stage has one responsibility, and each is a place where noise can be removed.

1. Collect. Monitoring sources send events into OBM.
2. Enrich and correlate. OBM resolves the related CI in the RTSM, applies event correlation, suppresses duplicates and identifies cause and symptom events.
3. Select. A forwarding rule decides which events are actionable enough to leave OBM.
4. Create or update the incident. The middleware creates a ServiceNow incident, or updates an existing one, and links it to the right cmdb_ci record.
5. Synchronise the lifecycle. Changes in either system flow back, so a resolved incident closes the event and a cleared event updates the incident.

Most alert storms happen because stages 2 and 3 are skipped and everything is forwarded directly from stage 1 to stage 4.

Design pattern catalogue

The table summarises the patterns covered in this guide. Each is explained in more detail below.

Pattern 1: Forward only what is actionable

Problem: Not every event needs a human. Warnings that clear themselves, informational messages and events from test environments create noise.

Solution: Define a forwarding rule in OBM based on clear criteria, for example:

• Severity is Major or Critical.
• The related CI belongs to a production environment.
• The event is a cause event, not a symptom (see pattern 2).
• The event has not been acknowledged or resolved by an automated action within a short grace period.

The grace period is underrated. Many transient events clear within a few minutes; waiting briefly before forwarding avoids opening incidents that would be closed as "no fault found".

Pattern 2: Correlate before you forward

Problem: When a core switch fails, every server, database and application behind it raises its own event. Forwarding all of them opens dozens of incidents for one cause.

Solution: Use OBM's event correlation capabilities, which use the topology in the RTSM to relate symptom events to a cause event. Forward only the cause event, and attach the symptom count or a summary to the incident description so the resolver group understands the blast radius. If later symptom events arrive, they update the existing incident instead of opening new ones.

Pattern 3: One event, one incident

Problem: If the middleware times out after ServiceNow created the incident but before it received the response, a retry can create a second incident.

Solution: Store a correlation key on both records. On the ServiceNow side, the correlation_id field on the incident table is the usual place for the OBM event ID. On the OBM side, write the ServiceNow incident number into an event attribute such as a custom attribute or the external reference of the event. Before creating anything, the middleware checks whether an incident with that correlation ID already exists.

How this works in ZigiOps: ZigiOps stores the OBM event ID in the incident's correlation_id field and the incident number on the event, and checks that correlation before creating anything. A retry therefore updates the existing incident instead of creating a second one.

Pattern 4: Update, don't recreate

Problem: A recurring problem produces the same event repeatedly. Each occurrence becomes a new incident.

Solution: Rely on OBM's duplicate suppression so repeated events increase a duplicate count on the original event rather than creating new ones. In the middleware, treat a changed duplicate count, a severity change or new annotations as updates to the existing incident, for example as work notes. Decide explicitly what happens if the event recurs after the incident was resolved: reopen the incident within a defined window, or create a new incident with a reference to the previous one.

Pattern 5: Bind to the right configuration item

Problem: Incidents without a configuration item cannot be routed, cannot show impacted services and make problem management harder.

Solution: Agree how CIs in the OBM RTSM are matched to records in the ServiceNow CMDB (cmdb_ci and its child tables). Common matching keys are the fully qualified host name, an IP address or a shared unique ID populated by discovery. Then use the CI to drive assignment: the incident's assignment group can come from the CI's support group in ServiceNow. If no matching CI is found, route the incident to a triage group and log the gap, rather than failing silently.

Pattern 6: Map severity to impact and urgency

Problem: Mapping OBM "Critical" directly to ServiceNow "Priority 1" turns every critical event into a major incident, even for a non-critical service.

Solution: ServiceNow calculates priority from impact and urgency. Let event severity drive urgency, and let the business criticality of the affected CI or service drive impact.

How this works in ZigiOps: In ZigiOps this is a conditional mapping configured in the UI: severity sets urgency, a lookup on the CI or service sets impact, and ServiceNow calculates priority as usual. No scripts are needed on either side.

Pattern 7: Close the loop in both directions

Problem: Operators see open events in OBM for incidents that were fixed hours ago, or the service desk keeps incidents open after monitoring shows the service has recovered.

Solution: Synchronise the lifecycle. Typical rules:

• When the incident is assigned or moves to In Progress, set the OBM event to "in progress" and record the assignee or group as an annotation.
• When the incident is resolved, close the OBM event.
• When OBM receives a "Normal" event that clears the original problem, add a work note to the incident. Whether this also resolves the incident automatically is a policy choice: many organisations allow it only for specific low-risk event types.
• Sync incident work notes to event annotations, and OBM annotations to work notes, filtered so automated chatter does not flood either side.

In ZigiOps, this is one integration with operations in each direction: create and update from OBM to ServiceNow, and update from ServiceNow back to OBM. Changes made by the integration user are ignored, so updates do not loop.

Pattern 8: Protect against floods

Problem: A data centre issue produces a spike that even correlation does not fully absorb.

Solution: Add a throttle in the middleware, such as a maximum number of incidents per CI or per service in a short window, and an alert to the operations bridge when the threshold is hit. During a known major incident, operators should be able to pause forwarding for an affected service without stopping the whole integration.

Choosing the middleware for ServiceNow integration

OBM and ServiceNow can be connected in several ways, and the patterns above apply to all of them.

• Vendor-provided connectors. OpenText provides integration options for ServiceNow, and ServiceNow offers its own event management capabilities, which use the em_event and em_alert tables if your organisation licenses ServiceNow ITOM. Check the current documentation for the versions you run.
• Custom scripts and REST APIs. Full control, but you own correlation, retries and maintenance.
• Integration platforms. General iPaaS tools or dedicated IT operations integration platforms such as ZigiOps, which offer OBM and ServiceNow connectors with bidirectional sync and conditional mapping as configuration.

When evaluating any option, ask whether it supports correlation IDs, conditional mapping for severity, bidirectional lifecycle sync, retries without duplication and an audit trail of what was sent. ZigiOps covers these points as configuration, does not store the transferred data and is ISO 27001 certified, which matters when event data contains host names and IP addresses.

Testing the integration

Before going live, test the patterns rather than just the happy path:

1. Send a single critical event and confirm one incident with the correct CI, urgency and impact.
2. Send the same event five times and confirm one incident with updates, not five incidents.
3. Simulate a topology failure and confirm one incident for the cause event.
4. Resolve the incident and confirm the OBM event closes.
5. Send a clearing event and confirm the expected work note or resolution.
6. Make ServiceNow unreachable for a few minutes and confirm events are queued and delivered once, without duplicates.

Frequently asked questions

What middleware integrates ServiceNow with OBM?

Options include vendor-provided connectors, custom REST integrations and third-party integration platforms such as ZigiOps. The right choice depends on whether you need bidirectional lifecycle sync, conditional mapping and duplicate protection without writing code.

Can ZigiOps sync OBM events and ServiceNow incidents in both directions?

Yes. It creates and updates incidents from OBM events, and syncs incident states, assignments and work notes back to the events as annotations and status changes, with correlation and loop prevention built in.

How do I automatically create incidents in ServiceNow from OBM events?

Define a forwarding rule in OBM for actionable events, then use middleware to create a ServiceNow incident with a correlation ID, the matching configuration item and urgency and impact derived from severity and service criticality.

How do I prevent duplicate incidents from monitoring events?

Correlate and de-duplicate in OBM first, store the event ID in the incident's correlation_id field, and have the middleware update the existing incident when the same event recurs.

Should a cleared event resolve the ServiceNow incident automatically?

Only for well-understood, low-risk event types. For most incidents, add a work note and let the resolver confirm, so you do not hide intermittent problems.

Do I need ServiceNow Event Management to integrate OBM?

No. You can create incidents directly. ServiceNow Event Management is an option if you want to consolidate events inside ServiceNow, but OBM already performs consolidation and correlation, so many organisations integrate at the incident level.

Key takeaways

• Treat the OBM to ServiceNow integration as an event flow with five stages, not a single connector.
• Filter and correlate in OBM before anything reaches ServiceNow.
• Use correlation IDs and update logic so one problem means one incident.
• Bind every incident to the correct CMDB CI and derive priority from both severity and service criticality.
• Synchronise the lifecycle in both directions and test duplicate, flood and outage scenarios before go-live.
• ZigiOps connects OBM and ServiceNow without code, with correlation IDs, conditional severity mapping and bidirectional lifecycle sync.

Supported Software