<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Integrating Dynatrace with ServiceNow Event Management in Alerting</title>
    <link>https://community.dynatrace.com/t5/Alerting/Integrating-Dynatrace-with-ServiceNow-Event-Management/m-p/303757#M6453</link>
    <description>&lt;DIV class=""&gt;&lt;SPAN&gt;I would keep the integration fairly simple. Since ServiceNow Event Management is event-based, I would send Dynatrace events into ServiceNow and let ServiceNow handle the processing afterwards, such as deduplication, CI binding, alert creation, assignment and incident creation.&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;P&gt;I would not use Dynatrace Alerting Profiles to determine resolver groups or to replicate ServiceNow assignment logic. Doing so would quickly result in a large number of Alerting Profiles for individual applications or support teams, which becomes difficult to maintain and scale.&lt;/P&gt;&lt;P class=""&gt;I would mainly use Alerting Profiles to determine &lt;STRONG&gt;which events or problems are relevant enough to be forwarded, and after what duration&lt;/STRONG&gt;, in order to prevent over-alerting. For example, an availability issue might be forwarded immediately, while a slowdown or resource issue may only be forwarded after it has persisted for a certain amount of time.&lt;/P&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;P class=""&gt;For the actual severity, I would use the severity of the Dynatrace event as the starting point. Dynatrace now has a standardized &lt;A href="https://docs.dynatrace.com/docs/analyze-explore-automate/alerting-and-notifications/standardized-event-severity#severity-storage-in-grail" target="_self"&gt;event.severity&lt;/A&gt; model from 1 to 5: Critical, Major, Minor, Warning and Informational. A Problem inherits the highest severity of the events correlated into that Problem.&lt;BR /&gt;&lt;BR /&gt;This is especially interesting for custom anomaly detectors, because you can explicitly set an event.severity on those events. This allows you to classify custom alerts consistently instead of relying only on their event type or category.&lt;/P&gt;&lt;P class=""&gt;I would also avoid directly mapping Dynatrace severity to an assignment group. Severity tells you &lt;STRONG&gt;how serious the issue is&lt;/STRONG&gt;, but not necessarily &lt;STRONG&gt;who is responsible for resolving it&lt;/STRONG&gt;. The assignment group should ideally be determined based on the affected or root-cause CI, ownership information and CMDB relationships in ServiceNow.&lt;/P&gt;&lt;P&gt;&lt;U&gt;So in short:&lt;/U&gt; use Alerting Profiles primarily to control what gets forwarded and when, in order to reduce noise. Use event.severity to consistently describe the technical severity of the event, including custom anomaly events. Then let ServiceNow Event Management handle CI binding, Event Management correlation/deduplication, ownership, assignment and incident creation.&lt;/P&gt;&lt;P&gt;This also prevents ending up with a large number of Alerting Profiles for every application or support team.&lt;/P&gt;</description>
    <pubDate>Tue, 25 Aug 2026 11:42:50 GMT</pubDate>
    <dc:creator>michiel_otten</dc:creator>
    <dc:date>2026-08-25T11:42:50Z</dc:date>
    <item>
      <title>Integrating Dynatrace with ServiceNow Event Management</title>
      <link>https://community.dynatrace.com/t5/Alerting/Integrating-Dynatrace-with-ServiceNow-Event-Management/m-p/303201#M6436</link>
      <description>&lt;P&gt;Hi&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;We are integrating Dynatrace with ServiceNow Event Management and need guidance on the recommended mapping strategy.&lt;/P&gt;
&lt;P&gt;We receive two types of events:&lt;/P&gt;
&lt;OL&gt;
&lt;LI&gt;Davis Problems&amp;nbsp;&lt;/LI&gt;
&lt;LI&gt;Custom Events / Anomaly Detector alerts&amp;nbsp;&lt;/LI&gt;
&lt;/OL&gt;
&lt;P&gt;What is Dynatrace's recommended approach for:&lt;/P&gt;
&lt;UL&gt;
&lt;LI&gt;Differentiating these event types within ServiceNow?&lt;/LI&gt;
&lt;LI&gt;
&lt;P&gt;Map directly from Severity Dynatrace to Severity ServiceNow?&amp;nbsp;&lt;/P&gt;
&lt;/LI&gt;
&lt;LI&gt;Routing incidents to different assignment groups?&lt;/LI&gt;
&lt;LI&gt;Avoiding duplicate incidents when a Davis Problem and a Custom Alert are generated for the same root cause?&lt;/LI&gt;
&lt;/UL&gt;
&lt;P&gt;Is there any standard procedures to mapping to ServieNow?&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;span class="lia-inline-image-display-wrapper lia-image-align-inline" image-alt="DB1_0-1786609707958.jpeg"&gt;&lt;img src="https://community.dynatrace.com/t5/image/serverpage/image-id/33933i56CAEFEED2EF1955/image-size/medium?v=v2&amp;amp;px=400" alt="DB1_0-1786609707958.jpeg" title="DB1_0-1786609707958.jpeg" /&gt;&lt;/span&gt;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;Thank you&lt;/P&gt;</description>
      <pubDate>Mon, 17 Aug 2026 05:46:07 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Alerting/Integrating-Dynatrace-with-ServiceNow-Event-Management/m-p/303201#M6436</guid>
      <dc:creator>DB1</dc:creator>
      <dc:date>2026-08-17T05:46:07Z</dc:date>
    </item>
    <item>
      <title>Re: Integrating Dynatrace with ServiceNow Event Management</title>
      <link>https://community.dynatrace.com/t5/Alerting/Integrating-Dynatrace-with-ServiceNow-Event-Management/m-p/303215#M6437</link>
      <description>&lt;P&gt;is there any suggestion on the following approaches? Do you think of the following approaches would work and would significantly simplify the integration whilst reducing the number of Dynatrace alerting profiles?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;&amp;nbsp;Route by Dynatrace Event Type&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;Dynatrace Event Type&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ServiceNow Assignment Group&lt;/P&gt;&lt;P&gt;-------------------------------------------------------&lt;BR /&gt;&amp;nbsp;OPEN Problem&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; Operational Team&lt;/P&gt;&lt;P&gt;OPEN Custom&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Relevant Application Support Team&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Route by Alerting Profile&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;For SEV1 and SEV2:&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;IF Alert Source = SGO-Dynatrace&lt;/P&gt;&lt;P&gt;AND Alerting Profile = &lt;SPAN&gt;Ops_operationalTeams_Critical&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;THEN Assignment Group = Operational Team&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;For SEV3 and SEV4&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;IF Alert Source = SGO-Dynatrace&lt;/P&gt;&lt;P&gt;AND Alerting Profile &lt;SPAN&gt;= Ops_ServiceTeams_Standard&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;THEN Assignment Group = Application Owner&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;This approach would allow us to standardise the configuration and maintain only two Dynatrace alerting profiles:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;STRONG&gt;Ops_OperationalTeams_Critical&lt;/STRONG&gt; (SEV1/SEV2)&lt;/LI&gt;&lt;LI&gt;&lt;STRONG&gt;Ops_ServiceTeams_Standard&lt;/STRONG&gt; (SEV3/SEV4)&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;This reduces ongoing administration effort and avoids the need to create and maintain multiple alerting profiles for individual services.&lt;/P&gt;</description>
      <pubDate>Thu, 13 Aug 2026 12:39:31 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Alerting/Integrating-Dynatrace-with-ServiceNow-Event-Management/m-p/303215#M6437</guid>
      <dc:creator>DB1</dc:creator>
      <dc:date>2026-08-13T12:39:31Z</dc:date>
    </item>
    <item>
      <title>Re: Integrating Dynatrace with ServiceNow Event Management</title>
      <link>https://community.dynatrace.com/t5/Alerting/Integrating-Dynatrace-with-ServiceNow-Event-Management/m-p/303753#M6452</link>
      <description>&lt;P&gt;is there anyone has better solution mapping directly severity from Dynatrace to Servicenow?&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 25 Aug 2026 10:41:47 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Alerting/Integrating-Dynatrace-with-ServiceNow-Event-Management/m-p/303753#M6452</guid>
      <dc:creator>DB1</dc:creator>
      <dc:date>2026-08-25T10:41:47Z</dc:date>
    </item>
    <item>
      <title>Re: Integrating Dynatrace with ServiceNow Event Management</title>
      <link>https://community.dynatrace.com/t5/Alerting/Integrating-Dynatrace-with-ServiceNow-Event-Management/m-p/303757#M6453</link>
      <description>&lt;DIV class=""&gt;&lt;SPAN&gt;I would keep the integration fairly simple. Since ServiceNow Event Management is event-based, I would send Dynatrace events into ServiceNow and let ServiceNow handle the processing afterwards, such as deduplication, CI binding, alert creation, assignment and incident creation.&lt;/SPAN&gt;&lt;/DIV&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;DIV class=""&gt;&lt;P&gt;I would not use Dynatrace Alerting Profiles to determine resolver groups or to replicate ServiceNow assignment logic. Doing so would quickly result in a large number of Alerting Profiles for individual applications or support teams, which becomes difficult to maintain and scale.&lt;/P&gt;&lt;P class=""&gt;I would mainly use Alerting Profiles to determine &lt;STRONG&gt;which events or problems are relevant enough to be forwarded, and after what duration&lt;/STRONG&gt;, in order to prevent over-alerting. For example, an availability issue might be forwarded immediately, while a slowdown or resource issue may only be forwarded after it has persisted for a certain amount of time.&lt;/P&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;/DIV&gt;&lt;P class=""&gt;For the actual severity, I would use the severity of the Dynatrace event as the starting point. Dynatrace now has a standardized &lt;A href="https://docs.dynatrace.com/docs/analyze-explore-automate/alerting-and-notifications/standardized-event-severity#severity-storage-in-grail" target="_self"&gt;event.severity&lt;/A&gt; model from 1 to 5: Critical, Major, Minor, Warning and Informational. A Problem inherits the highest severity of the events correlated into that Problem.&lt;BR /&gt;&lt;BR /&gt;This is especially interesting for custom anomaly detectors, because you can explicitly set an event.severity on those events. This allows you to classify custom alerts consistently instead of relying only on their event type or category.&lt;/P&gt;&lt;P class=""&gt;I would also avoid directly mapping Dynatrace severity to an assignment group. Severity tells you &lt;STRONG&gt;how serious the issue is&lt;/STRONG&gt;, but not necessarily &lt;STRONG&gt;who is responsible for resolving it&lt;/STRONG&gt;. The assignment group should ideally be determined based on the affected or root-cause CI, ownership information and CMDB relationships in ServiceNow.&lt;/P&gt;&lt;P&gt;&lt;U&gt;So in short:&lt;/U&gt; use Alerting Profiles primarily to control what gets forwarded and when, in order to reduce noise. Use event.severity to consistently describe the technical severity of the event, including custom anomaly events. Then let ServiceNow Event Management handle CI binding, Event Management correlation/deduplication, ownership, assignment and incident creation.&lt;/P&gt;&lt;P&gt;This also prevents ending up with a large number of Alerting Profiles for every application or support team.&lt;/P&gt;</description>
      <pubDate>Tue, 25 Aug 2026 11:42:50 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Alerting/Integrating-Dynatrace-with-ServiceNow-Event-Management/m-p/303757#M6453</guid>
      <dc:creator>michiel_otten</dc:creator>
      <dc:date>2026-08-25T11:42:50Z</dc:date>
    </item>
    <item>
      <title>Re: Integrating Dynatrace with ServiceNow Event Management</title>
      <link>https://community.dynatrace.com/t5/Alerting/Integrating-Dynatrace-with-ServiceNow-Event-Management/m-p/303813#M6455</link>
      <description>&lt;DIV&gt;Is it possible to set or customize the severity for the built-in Kubernetes alerts in Dynatrace, or are the severities fixed by the default anomaly detection configuration?&lt;/DIV&gt;</description>
      <pubDate>Wed, 26 Aug 2026 15:02:32 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Alerting/Integrating-Dynatrace-with-ServiceNow-Event-Management/m-p/303813#M6455</guid>
      <dc:creator>DB1</dc:creator>
      <dc:date>2026-08-26T15:02:32Z</dc:date>
    </item>
    <item>
      <title>Re: Integrating Dynatrace with ServiceNow Event Management</title>
      <link>https://community.dynatrace.com/t5/Alerting/Integrating-Dynatrace-with-ServiceNow-Event-Management/m-p/303817#M6456</link>
      <description>&lt;P&gt;I think I have a helpful answer to your original question but first I would like to ask you about this reply. Are your kubernetes related alerts particularly noisy? Are you trying to use their severity classifications to adjust the logic for when to trigger an incident email notification in servicenow?&lt;/P&gt;</description>
      <pubDate>Wed, 26 Aug 2026 16:43:26 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Alerting/Integrating-Dynatrace-with-ServiceNow-Event-Management/m-p/303817#M6456</guid>
      <dc:creator>nick-p-montana</dc:creator>
      <dc:date>2026-08-26T16:43:26Z</dc:date>
    </item>
  </channel>
</rss>

