topic Re: ServiceNow Integration – Service Impact alerts are not populating Host Name in Incident in Open Q&A

ServiceNow Integration – Service Impact alerts are not populating Host Name in Incident

Sohel_Rashid — Sun, 02 Aug 2026 14:39:13 GMT

Hi Team,

We are integrating Dynatrace Managed with ServiceNow using the ServiceNow integration.

We have observed that for Service Impact problems, the Host Name is not being populated in the ServiceNow incident. Instead, the Node field displays the affected service/process (e.g., Bootstrap Spring Boot, Tomcat/localhost, application), while the Configuration Item (CI) remains empty for most incidents.

Our ServiceNow operations team is requesting that the Host Name be included in the incident so they can quickly identify the impacted server without navigating back to Dynatrace.

Current Behavior:

Problem type: Service Impact
Node field: Displays service/process name
Configuration Item (CI): Empty
Host Name: Not available in the incident

Expected Behavior:

The ServiceNow incident should include the Host Name (or affected Host entity) for service impact events.
If multiple hosts are impacted, at least the primary affected host or a list of affected hosts should be available in the incident payload.

Questions:

Is it possible to populate the Host Name for Service Impact problems in the ServiceNow incident?
Is this achievable through Problem Notification Payload Customization or ServiceNow Mapping?
Has anyone implemented a custom payload to include the affected host entity?
If the impacted entity is a service rather than a host, what is the recommended approach to expose the underlying host information in ServiceNow?

I've attached a screenshot showing the current behavior where the Node contains the service name, but the Host Name/CI is missing.

Any guidance or best practices would be greatly appreciated.

Thanks in advance!

Re: ServiceNow Integration – Service Impact alerts are not populating Host Name in Incident

sujit_k_singh — Sun, 02 Aug 2026 23:32:30 GMT

Hi @Sohel_Rashid

This is expected behavior — for Service Impact problems, the primary affected entity is the Service (or Process Group Instance), not the Host, so ServiceNow's default mapping pulls Node/CI from that entity, which is often empty or not host-level.

1. Is it possible to populate the Host Name for Service Impact problems?
Yes. You can expose host information either by customizing the notification payload from Dynatrace or using ServiceNow transformation/binding logic.

2. Is this achievable through Payload Customization or ServiceNow Mapping? Both.

ServiceNow Mapping: If using ServiceNow ITOM/Event Management, CI binding rules can automatically

resolve the host via CMDB relationships.

Payload Customization: Standard Webhook placeholders like {ImpactedEntity} only send the service name, but rich placeholders can pass the full topology context to ServiceNow.

3. Has anyone implemented a custom payload to include the affected host entity?
Yes. Unlike standard single-string placeholders, {ProblemDetailsJSONv2} injects the full V2 Problem JSON containing all underlying entity relationships. ServiceNow can then parse this JSON payload to extract host names directly.

4. Recommended approach to expose underlying host info for Service alerts?

Parse {ProblemDetailsJSONv2} in Webhook Payload - Send the V2 problem JSON via Webhook and extract the host details from evidenceDetails using a ServiceNow Transform Map script.

ServiceNow Scripted Lookup via API (Best for Multi-Host Services) - When ServiceNow receives the SERVICE-XXXX ID, a Transform Script calls the Dynatrace Monitored Entities API to pull its runsOn Host entities.

Thanks,

Sujit

Re: ServiceNow Integration – Service Impact alerts are not populating Host Name in Incident

Sohel_Rashid — Mon, 03 Aug 2026 11:20:39 GMT

Hi @sujit_k_singh ,

Thank you for the detailed explanation. This is very helpful and clarifies why the Host Name is not populated for Service Impact problems by default.

I have one follow-up question:

From the Dynatrace side, is there any additional configuration required to expose the underlying host information? For example, do we need to customize the ServiceNow webhook payload (using {ProblemDetailsJSONv2}) or make any other configuration changes in Dynatrace?

Or can this requirement be achieved entirely from the ServiceNow side by parsing the existing payload and implementing CMDB binding/transform logic?

Could you please let us know which approach you recommend and whether any changes are required in the Dynatrace configuration?

Thanks again for your guidance.

Best regards,
Sohel Rashid

Re: ServiceNow Integration – Service Impact alerts are not populating Host Name in Incident

AntonPineiro — Mon, 03 Aug 2026 12:49:06 GMT

Hi,

Maybe you can create a tagging rule for every host. It means, host is going to have hostname as tag and problem would inherit the tag.

When problem is sent to SNOW, it would be sent with another tags information.

Best regards

Re: ServiceNow Integration – Service Impact alerts are not populating Host Name in Incident

sujit_k_singh — Tue, 04 Aug 2026 06:07:54 GMT

Hi @Sohel_Rashid

Here is a summary of how to handle this from the Dynatrace side:

Option A: Payload Customization ({ProblemDetailsJSONv2})

Go to Settings ->Integration ->Problem notifications and edit your integration.

Add {ProblemDetailsJSONv2} to the custom JSON body. This includes the full evidenceDetails array, allowing your ServiceNow Transform Map to extract the underlying Host Name.

Option B: As suggested by @AntonPineiro Host Tagging Rule, Automatically applied tags and create a rule for Hosts.

Caveat: Tags only flow into Service Impact problems if Dynatrace explicitly ties that host to the root cause. If a service spans multiple hosts, this can be hit-or-miss.

i would say first try option A to ensure ServiceNow always gets full topology context.

Thanks,

Sujit