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

[Sohel_Rashid]

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:

1. Is it possible to populate the Host Name for Service Impact problems in the ServiceNow incident?
2. Is this achievable through Problem Notification Payload Customization or ServiceNow Mapping?
3. Has anyone implemented a custom payload to include the affected host entity?
4. 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!

[sujit_k_singh]

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

[Sohel_Rashid]

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

[AntonPineiro]

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

[sujit_k_singh]

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