<?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 Classic Tags (Manual/Automatic) vs Primary Tags (Grail based tagging) in Open Q&amp;A</title>
    <link>https://community.dynatrace.com/t5/Open-Q-A/Classic-Tags-Manual-Automatic-vs-Primary-Tags-Grail-based/m-p/300637#M39171</link>
    <description>&lt;P&gt;Hey guys,&lt;/P&gt;&lt;P&gt;I wanted to get thoughts on this. Within my company we use tagging heavily for not just filtering, but for escalation.&lt;/P&gt;&lt;P&gt;The process is basically like this "Tagged Resource goes down --&amp;gt; Problem opened --&amp;gt; Problem sent to Moogsoft with meta data (process name, tags, issue, etc) --&amp;gt; Moogsoft investigates the tags --&amp;gt; Based on the tags, it will either ignore, create a ticket, or escalate to NOC and create a ticket".&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;P&gt;We also using tagging in other ways, but above is the primary way. Now, we found out that automatic tagging will no longer exist with the Grail backend and will only be tied to classic entities, thus we won't be able to create segments, use the Smartscapes 2.0 app properly, use some DQL commands that would do advanced filtering based on autotags, etc.&lt;/P&gt;&lt;P&gt;The "new" method is going primary tags, which are basically tags that are applied at source (at the app level). Although this sounds good on paper, as I am sure that is where the decision was made without real world feedback, this presents a problem for us. Within my company, we do not only have one Development team and one Operations team, under one VP, with one Director. We have a hundred different development teams with 100 different VP's, Operations teams with different VP's/Directors, etc. The Development and Operations teams are already extremely overwhelmed with the amount of work they have going on, which makes the Monitoring team less of a priority (defining tags), than their priority to build/update the applications.&lt;/P&gt;&lt;P&gt;Then we also throw in items that do not have OneAgent installed (Items added through extensions, such as NTWK devices). We cannot define tags at source and even if we could, I highly doubt the NTWK team cares enough to let us tell them to do it.&lt;/P&gt;&lt;P&gt;To add alittle more to this. Even though standards are set, we also noticed in our Azure environment that some tags are are follows: "SupportTeam:" "Support Team:" "SupportTeam :" "Support Teams :". All have small difference, but were applied for the same reason. It would be safe to assume that the same issue would happened with a Development/Operations team defining it at Source.&lt;/P&gt;&lt;P&gt;We discovered this issue when trying to create segments for the Smartscape 2.0 app, and based on recent feedback, I was told that I may just have to live with it.&lt;/P&gt;&lt;P&gt;I wanted to get everyone elses thoughts on this before I escalate it through our CSM, as maybe I am expecting something to exist that should just not exist anymore.&lt;/P&gt;&lt;P&gt;Thoughts, please..&lt;/P&gt;</description>
    <pubDate>Thu, 11 Jun 2026 19:39:46 GMT</pubDate>
    <dc:creator>david_manes</dc:creator>
    <dc:date>2026-06-11T19:39:46Z</dc:date>
    <item>
      <title>Classic Tags (Manual/Automatic) vs Primary Tags (Grail based tagging)</title>
      <link>https://community.dynatrace.com/t5/Open-Q-A/Classic-Tags-Manual-Automatic-vs-Primary-Tags-Grail-based/m-p/300637#M39171</link>
      <description>&lt;P&gt;Hey guys,&lt;/P&gt;&lt;P&gt;I wanted to get thoughts on this. Within my company we use tagging heavily for not just filtering, but for escalation.&lt;/P&gt;&lt;P&gt;The process is basically like this "Tagged Resource goes down --&amp;gt; Problem opened --&amp;gt; Problem sent to Moogsoft with meta data (process name, tags, issue, etc) --&amp;gt; Moogsoft investigates the tags --&amp;gt; Based on the tags, it will either ignore, create a ticket, or escalate to NOC and create a ticket".&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;&lt;P&gt;We also using tagging in other ways, but above is the primary way. Now, we found out that automatic tagging will no longer exist with the Grail backend and will only be tied to classic entities, thus we won't be able to create segments, use the Smartscapes 2.0 app properly, use some DQL commands that would do advanced filtering based on autotags, etc.&lt;/P&gt;&lt;P&gt;The "new" method is going primary tags, which are basically tags that are applied at source (at the app level). Although this sounds good on paper, as I am sure that is where the decision was made without real world feedback, this presents a problem for us. Within my company, we do not only have one Development team and one Operations team, under one VP, with one Director. We have a hundred different development teams with 100 different VP's, Operations teams with different VP's/Directors, etc. The Development and Operations teams are already extremely overwhelmed with the amount of work they have going on, which makes the Monitoring team less of a priority (defining tags), than their priority to build/update the applications.&lt;/P&gt;&lt;P&gt;Then we also throw in items that do not have OneAgent installed (Items added through extensions, such as NTWK devices). We cannot define tags at source and even if we could, I highly doubt the NTWK team cares enough to let us tell them to do it.&lt;/P&gt;&lt;P&gt;To add alittle more to this. Even though standards are set, we also noticed in our Azure environment that some tags are are follows: "SupportTeam:" "Support Team:" "SupportTeam :" "Support Teams :". All have small difference, but were applied for the same reason. It would be safe to assume that the same issue would happened with a Development/Operations team defining it at Source.&lt;/P&gt;&lt;P&gt;We discovered this issue when trying to create segments for the Smartscape 2.0 app, and based on recent feedback, I was told that I may just have to live with it.&lt;/P&gt;&lt;P&gt;I wanted to get everyone elses thoughts on this before I escalate it through our CSM, as maybe I am expecting something to exist that should just not exist anymore.&lt;/P&gt;&lt;P&gt;Thoughts, please..&lt;/P&gt;</description>
      <pubDate>Thu, 11 Jun 2026 19:39:46 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Open-Q-A/Classic-Tags-Manual-Automatic-vs-Primary-Tags-Grail-based/m-p/300637#M39171</guid>
      <dc:creator>david_manes</dc:creator>
      <dc:date>2026-06-11T19:39:46Z</dc:date>
    </item>
    <item>
      <title>Re: Classic Tags (Manual/Automatic) vs Primary Tags (Grail based tagging)</title>
      <link>https://community.dynatrace.com/t5/Open-Q-A/Classic-Tags-Manual-Automatic-vs-Primary-Tags-Grail-based/m-p/300643#M39173</link>
      <description>&lt;P&gt;Being brutally honest, the whole rollout of Segments, removal of tagging, and IAM has been a trainwreck. No idea why Dynatrace seem to be plugging their ears at all the negative feedback they've been receiving on these things. I understand that this is a transitory phase for the platform, but we're not shelling out hundreds of thousands of dollars for a transitory product, and so if these product shortcomings remain in Gen3 in the long-term, I can't imagine myself continuing with using Dynatrace for an observability platform.&lt;/P&gt;</description>
      <pubDate>Thu, 11 Jun 2026 21:47:38 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Open-Q-A/Classic-Tags-Manual-Automatic-vs-Primary-Tags-Grail-based/m-p/300643#M39173</guid>
      <dc:creator>siavash1996</dc:creator>
      <dc:date>2026-06-11T21:47:38Z</dc:date>
    </item>
  </channel>
</rss>

