Dynatrace ServiceNow integration is primarily a technical integration topic. It connects Dynatrace observability data with ServiceNow ITOM/ITSM capabilities so that monitoring problems, events, configuration items, topology, and operational context can participate in ServiceNow workflows.

The implementation details below focus on current integration patterns and distinguish the classic Dynatrace notification approach from newer ServiceNow Service Graph Connector capabilities. ServiceNow published a new Dynatrace SaaS Service Graph Connector direction in 2026, including deeper support for Dynatrace 3rd-generation data models and Grail/DQL.

Introduction

Dynatrace ServiceNow integration is used to connect application and infrastructure observability with enterprise IT operations processes. In a typical enterprise, Dynatrace detects application failures, performance degradation, infrastructure problems, or service-impacting events, while ServiceNow manages incidents, configuration items (CIs), service relationships, ownership, approvals, and operational workflows.

Without integration, an operations team may have to monitor Dynatrace in one console and manually create or investigate incidents in ServiceNow. That creates delays and, more importantly, loses technical context during incident handling.

With the integration in place, a flow can look like this:

Dynatrace → Problem/Event → ServiceNow Event Management → Alert → CI correlation → Incident/Automation

The integration can also work in the opposite direction for selected operational workflows, but the most common implementation pattern is to use Dynatrace as the observability source and ServiceNow as the IT operations and workflow platform.

Dynatrace documents three major ServiceNow integration areas: incident integration, event management integration, and CMDB integration.

For an Oracle-focused enterprise, this becomes particularly useful when Oracle Fusion Cloud, Oracle databases, middleware, APIs, cloud infrastructure, and surrounding applications are part of a larger service landscape. Dynatrace can provide the technical observability while ServiceNow provides the operational process layer.

What Is Dynatrace ServiceNow Integration?

Dynatrace ServiceNow integration allows monitoring and observability information generated by Dynatrace to be consumed by ServiceNow.

The information can include:

• Dynatrace-detected problems
• Events
• Hosts
• Processes
• Applications
• Services
• Service relationships
• Metrics
• Logs, depending on the connector and implementation
• Root-cause information
• Severity
• Affected entities

ServiceNow can then use this information for:

• Event Management
• Alert creation
• Incident creation
• CMDB enrichment
• Service mapping
• CI identification
• Operational dashboards
• Automation and remediation

ServiceNow’s observability connector architecture is designed around standard Service Graph concepts, while Dynatrace’s integration documentation also describes incident, event-management, and CMDB integration approaches.

An important distinction: events, alerts, and incidents

One of the most common implementation mistakes is treating these three objects as the same thing.

For example:

Dynatrace detects that an Oracle-related application service is experiencing a sustained response-time degradation.

That does not automatically mean that an Incident should immediately be created.

A mature implementation may first:

1. Receive the Dynatrace event.
2. Identify the affected CI.
3. Correlate related events.
4. Determine severity.
5. Check whether an existing alert already exists.
6. Suppress duplicate or secondary symptoms.
7. Create an incident only when business rules require it.

This distinction is critical when designing enterprise monitoring.

Real-World Integration Use Cases

Use Case 1 – Automatic Incident Creation

Consider an enterprise application hosted on OCI and monitored through Dynatrace.

Dynatrace detects:

• Application availability failure
• Increased error rate
• Multiple failed service requests

Instead of an operations engineer manually creating an incident, Dynatrace sends the problem to ServiceNow.

ServiceNow receives the information and creates an incident containing:

• Short description
• Description
• Severity
• Affected CI
• Dynatrace problem reference
• Technical details
• Monitoring source

Dynatrace documents that its incident integration can automatically create a ServiceNow incident for an automatically discovered problem.

Use Case 2 – CMDB Enrichment

Suppose Dynatrace identifies the following topology:

Customer Portal
      |
Application Service
      |
Process
      |
Linux Host
      |
Database

If that information is brought into ServiceNow, the CMDB can contain corresponding CIs and relationships.

Now, when an alert arrives, ServiceNow has more context than simply:

“Application is down.”

It can understand:

Application → Process → Host → Supporting infrastructure

This makes incident triage considerably more useful.

The Service Graph Connector for Observability–Dynatrace is designed to ingest observability information into ServiceNow, and ServiceNow describes the connector as supporting CI and service topology use cases.

Use Case 3 – Oracle Integration Monitoring

Consider an enterprise integration landscape:

Oracle Fusion HCM
       |
       ↓
Oracle Integration Cloud
       |
       ↓
Payroll / Banking / HR Application

Dynatrace may monitor the surrounding application infrastructure and APIs.

Suppose an integration service starts producing repeated HTTP 500 responses.

A practical operational workflow could be:

Dynatrace detects degradation
          ↓
Problem/event generated
          ↓
ServiceNow Event Management
          ↓
Event correlation
          ↓
Affected CI identified
          ↓
Alert created
          ↓
Incident created according to policy
          ↓
Support team investigates

The important point is that Dynatrace provides the technical evidence, while ServiceNow provides the operational workflow.

Architecture and Technical Flow

A simplified architecture is:

                 ┌─────────────────────┐
                 │      Dynatrace      │
                 │                     │
                 │ Hosts               │
                 │ Applications        │
                 │ Services            │
                 │ Problems            │
                 │ Metrics / Logs      │
                 └──────────┬──────────┘
                            │
                 API / Connector / Webhook
                            │
                            ▼
                 ┌─────────────────────┐
                 │     ServiceNow      │
                 │                     │
                 │ Event Management    │
                 │ Service Graph       │
                 │ CMDB                │
                 │ Alert Management    │
                 │ ITSM                │
                 └──────────┬──────────┘
                            │
                    Correlation / Rules
                            │
                            ▼
                 ┌─────────────────────┐
                 │ Incident / Workflow │
                 │ Automation / Teams  │
                 └─────────────────────┘

How the flow works

1. Dynatrace monitors the environment

Dynatrace collects telemetry and detects abnormal behavior.

For example:

• High response time
• Error rate increase
• Host failure
• Service failure
• Availability problem

2. Dynatrace creates a problem or event

Dynatrace correlates related events into problems where appropriate.

Dynatrace documentation describes a problem as a grouping of incidents/events that share a root cause.

3. Data is sent to ServiceNow

Depending on the selected architecture, this can use:

• ServiceNow integration
• Problem notifications
• Custom webhook
• Service Graph Connector
• Event Management connector
• Dynatrace Workflows

4. ServiceNow processes the information

ServiceNow can:

• Normalize the event
• Identify the source
• Match the CI
• Correlate related events
• Generate an alert
• Trigger an incident
• Invoke automation

5. Operations team handles the issue

The ServiceNow incident becomes part of the organization’s normal ITSM process.

Current Integration Considerations

There are multiple Dynatrace-ServiceNow approaches, so consultants should not automatically implement the first integration they find in an old project document.

Dynatrace’s current documentation notes that Problem Notifications are a Dynatrace Classic concept and recommends simple workflows for newer Dynatrace environments.

At the same time, ServiceNow’s 2026 material describes a newer Service Graph Connector for Observability – Dynatrace SaaS direction built around Dynatrace’s third-generation data model, Grail, and DQL.

Therefore, during a new implementation, first determine:

• Which Dynatrace platform/version is being used?
• Is the customer using Dynatrace SaaS?
• Is Grail being used?
• Which ServiceNow release is deployed?
• Which Service Graph Connector version is available?
• Is Event Management licensed?
• Is CMDB integration required?
• Is the requirement incident-only or full observability integration?

This prevents implementing an outdated architecture simply because an old project document exists.

Prerequisites

Before starting the implementation, validate the following.

Dynatrace prerequisites

You should have:

• Dynatrace environment
• Appropriate API/integration permissions
• Required API token or connection credentials
• Monitoring configuration
• Alerting/problem detection configuration
• Appropriate alerting profile or workflow logic

Dynatrace’s documented ServiceNow integration uses configuration on both the Dynatrace and ServiceNow sides.

ServiceNow prerequisites

Depending on the chosen implementation, you may need:

• ServiceNow ITSM
• ITOM/Event Management
• CMDB
• Service Graph capabilities
• Appropriate integration application
• Integration user
• Required roles
• Network connectivity
• Credential/connection configuration

For the Dynatrace Incident Integration application, Dynatrace documents web_service_admin and x_dynat_ruxit.Integration as required roles for the integration user.

Do not simply grant broad administrator access to an integration account because “it makes testing easier.” Define the minimum required privileges and validate them during testing.

Step-by-Step Build Process

Step 1 – Define the integration requirement

Before installing anything, document the required flow.

For example:

This becomes your integration design baseline.

Step 2 – Prepare the ServiceNow instance

Install the required Dynatrace integration components according to the ServiceNow Store and the connector architecture selected for your environment.

ServiceNow’s onboarding material identifies Service Graph Connector Central and Service Graph Connector for Observability – Dynatrace as components used for this connector approach.

For older/classic architectures, additional Event Management and observability components may be involved. ServiceNow’s connector documentation explicitly lists supporting components for the Service Graph Connector implementation.

Consultant tip: Do not copy plugin names from a three-year-old implementation document into a new environment without checking current Store availability and compatibility.

Step 3 – Create the integration connection

Configure the ServiceNow-side connection according to the connector’s Guided Setup.

Typical information includes:

• Dynatrace environment URL
• Authentication details
• Connection/credential alias
• Integration user
• Target environment
• Import configuration

Use credential aliases or the platform’s secure credential mechanism rather than embedding secrets inside scripts.

Step 4 – Configure Dynatrace

For a classic problem-notification implementation, Dynatrace documents the following general path:

Settings → Integration → Problem notifications → Add notification

Select ServiceNow and configure the ServiceNow instance information. The Dynatrace documentation also provides a test-notification option.

For newer Dynatrace environments, evaluate whether a workflow-based integration is more appropriate instead of building new dependencies on classic problem notifications.

Step 5 – Configure event processing

Do not send every monitoring event directly into Incident Management.

Define rules for:

• Severity
• Source
• Event class
• CI
• Environment
• Application
• Business service
• Event type
• Correlation
• Deduplication

For example:

Dynatrace severity = Critical
AND
Environment = Production
AND
Business Service is populated
AND
No active correlated alert exists

→ Create/route an incident.

Whereas:

Dynatrace severity = Warning
AND
Environment = Development

→ Keep as an alert without generating an incident.

This is one of the most important design decisions in the entire integration.

Step 6 – Configure CI correlation

A monitoring event is far more useful when ServiceNow knows which CI it belongs to.

Possible matching attributes may include:

• Host name
• Host identifier
• Dynatrace entity identifier
• Cloud resource identifiers
• Tags
• Application/service attributes

The CMDB identification and reconciliation process is important because simply importing CIs can create duplicates.

Dynatrace’s documentation notes that CMDB deduplication can use ServiceNow Identification and Reconciliation capabilities and custom identification rules.

Step 7 – Configure topology

If topology is part of the requirement, validate relationships rather than only individual CIs.

For example:

Application Service
       ↓
Process
       ↓
Host
       ↓
Infrastructure

ServiceNow’s current Dynatrace connector direction specifically emphasizes service topology and relationships, including host, process, service, and frontend relationships.

Step 8 – Configure incident behavior

Define what should happen when an alert is created.

Example:

Critical Alert
     ↓
Check existing incident
     ↓
Incident exists?
   /       \
 Yes        No
 ↓          ↓
Update    Create
existing  incident

This prevents a single technical problem from generating dozens of duplicate incidents.

Testing the Technical Component

Testing should be performed in phases rather than immediately using a production outage.

Test 1 – Connectivity

Send a test notification from Dynatrace.

Expected result:

• Request reaches ServiceNow.
• Authentication succeeds.
• Integration logs show successful processing.

Dynatrace provides a Send test notification capability for its documented ServiceNow notification setup.

Test 2 – Event ingestion

Generate a controlled monitoring event.

Expected result:

• Event appears in ServiceNow.
• Correct source is identified.
• Severity is mapped correctly.
• Timestamp is correct.

Test 3 – CI correlation

Generate an event against a known test host/application.

Expected result:

Dynatrace Event
      ↓
ServiceNow Alert
      ↓
Correct CI

If the event arrives but the CI is empty, investigate identification rules, entity identifiers, tags, and CMDB data quality.

Test 4 – Incident creation

Create a test condition that meets your critical-event criteria.

Expected result:

• Alert is generated.
• Correlation is performed.
• Incident is created only when appropriate.
• CI is populated.
• Assignment group is correct.

Test 5 – Duplicate event

Send the same event multiple times.

Expected result:

One operational issue should not produce a flood of duplicate incidents.

Validate:

• Event deduplication
• Alert correlation
• Incident correlation
• Event identifiers
• Repeated notification behavior

Test 6 – Closure

Resolve the test problem in Dynatrace.

Verify whether the intended ServiceNow alert/incident lifecycle is updated.

Dynatrace’s documented Incident Integration behavior includes marking the ServiceNow incident as resolved when the corresponding Dynatrace problem is closed.

Common Errors and Troubleshooting

1. Events arrive but no alerts are created

Check:

• Event filters
• Alerting rules
• Event source
• Event class
• Severity mapping
• Required ITOM configuration

Receiving data successfully does not necessarily mean ServiceNow will create an alert.

2. Alerts are created without a CI

Usually investigate:

• Entity identifier mapping
• Host-name mismatch
• Missing Dynatrace tags
• CMDB identification rules
• Missing CI
• Duplicate CIs

Do not solve this by manually populating the CI on every incident. Fix the identification process.

3. Too many incidents are generated

This is commonly a design issue rather than an integration failure.

Review:

• Severity thresholds
• Event correlation
• Alert grouping
• Deduplication
• Incident creation rules
• Suppression policies

A good monitoring integration should reduce operational noise, not move monitoring noise into another platform.

4. Duplicate CIs appear in CMDB

Review ServiceNow Identification and Reconciliation rules and the identifiers being supplied by Dynatrace.

The Dynatrace documentation specifically highlights CMDB Identification and Reconciliation as the mechanism for merging identical CIs.

5. Authentication fails

Check:

• Integration credentials
• Token validity
• User roles
• API permissions
• Endpoint URL
• Network access
• OAuth/token configuration where applicable

For a 403 response, do not immediately assume that the endpoint is wrong. Check whether the integration user actually has the required permission.

6. Topology becomes excessively large

Large Dynatrace environments can contain enormous numbers of entities.

Do not automatically import everything.

Use:

• Filtering
• Segmentation
• Scope restrictions
• Environment separation
• CI lifecycle policies

The current ServiceNow Dynatrace connector documentation describes filtering/segmentation and lifecycle considerations specifically to help control CMDB scale.

Best Practices for Dynatrace ServiceNow Integration

1. Design the event-to-incident policy first

Do not begin by asking:

“How do we send Dynatrace alerts to ServiceNow?”

Instead ask:

“Which technical conditions should create an operational action?”

That distinction leads to a much cleaner implementation.

2. Treat CMDB quality as part of the integration

If CI correlation is poor, ServiceNow operators will receive alerts without meaningful business context.

3. Avoid hardcoded credentials

Use secure connection and credential mechanisms.

4. Separate environments

Maintain clear separation between:

• Development
• Test
• Production

A test Dynatrace environment should not accidentally generate production incidents.

5. Establish severity mapping

Document exactly how Dynatrace severity translates to ServiceNow operational priority.

Do not allow each application team to invent its own mapping.

6. Start with a controlled application

For a large enterprise, do not onboard thousands of applications on day one.

Start with:

1. One application.
2. One service.
3. A few known CIs.
4. Critical events.
5. Controlled incident creation.

Then expand.

7. Monitor the integration itself

Create operational checks for:

• Failed API calls
• Authentication failures
• Processing failures
• Event backlog
• Missing CI correlation
• Duplicate incidents

The integration is itself a production service and should be monitored.

8. Account for the current Dynatrace architecture

For new implementations, explicitly assess whether the environment uses newer Dynatrace capabilities such as Grail and DQL and whether the available ServiceNow connector supports them.

ServiceNow’s 2026 connector update describes Dynatrace 3rd-generation changes, including Grail/DQL-based data access, Kubernetes/cloud entity modeling, and richer root-cause information.

FAQ

1. What is the main purpose of Dynatrace ServiceNow integration?

The primary purpose is to connect Dynatrace observability information with ServiceNow IT operations processes. This can include event ingestion, alert correlation, incident management, CI association, CMDB enrichment, and service topology.

2. Does every Dynatrace event create a ServiceNow incident?

No. A well-designed implementation normally separates events, alerts, and incidents. Event correlation and business rules should determine when an operational incident is actually required.

3. Can Dynatrace populate the ServiceNow CMDB?

Yes. Dynatrace-ServiceNow integration can support CMDB-related use cases, including importing monitored entities and relationships. The exact objects and capabilities depend on the connector architecture and versions being used. Dynatrace documents CMDB integration, while ServiceNow’s current connector direction includes CI and topology enrichment.

Summary

Dynatrace ServiceNow integration is more than a simple webhook that creates incidents. In a mature implementation, Dynatrace supplies observability and technical context, while ServiceNow provides the operational model for events, alerts, CIs, incidents, service relationships, and automation.

A practical architecture should therefore be designed around:

Observability
     ↓
Event ingestion
     ↓
Normalization
     ↓
CI identification
     ↓
Correlation
     ↓
Alert
     ↓
Incident / Automation

For new projects, consultants should also distinguish legacy/classic Dynatrace notification patterns from current workflow and Service Graph Connector capabilities. Dynatrace recommends workflows for newer environments instead of relying on the classic Problem Notification model, while ServiceNow’s 2026 Dynatrace SaaS connector work introduces deeper integration with Dynatrace’s newer data architecture.

For Oracle-centric enterprises, this architecture can sit alongside Oracle Fusion Cloud, Oracle Integration Cloud, OCI, databases, and other enterprise applications. Oracle Fusion Cloud Applications documentation for 26A should be used when the monitoring solution touches Oracle application components. The general Oracle documentation hub is available here: Oracle Fusion Cloud Applications documentation. For Oracle Time and Labor specifically, refer to the Implementing Time and Labor guide and the current Time and Labor documentation.