topic Re: Using workflows for problem notifications, alert profiles, and management zone in Alerting

Using workflows for problem notifications, alert profiles, and management zone

phongsakorn — Wed, 20 May 2026 06:45:40 GMT

Currently, we are trying to migrate from flow management zones, alert profiles, and problem integrations to use simple workflows for alerting. However, we found that segments cannot be used in workflows for filtering, and there is no delay feature like in alert profiles. Both features are still listed as product ideas.

https://community.dynatrace.com/t5/Product-ideas/Delay-on-the-Davis-Problem-trigger-in-workflow/idi-p/252329

Could you please provide an estimated release timeline for these features?

Re: Using workflows for problem notifications, alert profiles, and management zone

rpindel — Wed, 20 May 2026 22:34:17 GMT

Thanks for writing this up. I was coming to the Community to write up more-or-less the same. As we think about moving from Alerting Profiles/Management Zones/Integrations for alerting two things jumped out to us based on how the platform is currently implemented:

There is no way to invoke a Segment in a Workflow. While we understand the technical details behind why this is the case, it is a drastic change from the ease of Management Zones and also feels lacking with regards to Workflows that do not serve alerting purposes. We are still hopeful for work from the Workflow product team on bringing in Segments.
Alerting Profiles/Integrations allow us to alert on conditions and aside from any configured limits on the quantity, do not cost us anything extra. We understand that simple Workflows are no-cost but a simple Workflow consists of two actions - a trigger and something else like a Slack message - but some alerting flows would need at least three if not more actions, especially considering the lack of Segments to effectively isolate the correct Problem events. Workflows that have three or more actions are not considered simple and are charged. We are concerned this essentially changes alerting for no-cost to alerting for cost.

I am adding my comments here ahead of routing this RFE to our CSM.

Re: Using workflows for problem notifications, alert profiles, and management zone

sujit_k_singh — Mon, 25 May 2026 22:48:50 GMT

Hello @phongsakorn

I share the same concerns. To add to this thread:

On the delay feature: Until Dynatrace natively adds a delay to the Problem trigger, the workaround is to use a DQL re-check pattern — trigger fires instantly, then a subsequent action queries if the problem is still active after X minutes before notifying. It works, but it adds actions (and cost).

On the cost concern: This is the real issue. What was previously free (alerting profile + integration) now potentially costs DDUs once you exceed 2 actions in a workflow. Especially when you need extra actions just to work around missing features (delay, segment filtering).

Re: Using workflows for problem notifications, alert profiles, and management zone

sonja — Mon, 08 Jun 2026 07:33:16 GMT

Hi, thank you for the detailed post. Both concerns are ones we hear a lot during migrations, so let me give you some context.

Segments are not a replacement for Management Zones

This is the most important thing to understand upfront. Segments are a front-end filtering tool. They scope what you see in dashboards, notebooks, and apps. They are not designed to route events or trigger workflows.

Why segments don't work in workflow triggers

Workflow triggers run through OpenPipeline, which processes events at ingest time, before any segment definition is available. This is by design. When something goes wrong, you need your workflow to fire immediately and reliably. OpenPipeline is what makes that possible at scale. Supporting segments directly on triggers is not something we plan to add.

How to filter your workflow triggers today

Use the additional custom filter query field on the problem trigger. The most effective options:

Grail primary fields (see https://docs.dynatrace.com/docs/semantic-dictionary/tags/primary-fields)
Grail primary tags: customer-defined attributes attached to all telemetry at ingest, available across every signal consistently (see https://docs.dynatrace.com/docs/ingest-from/dynatrace-oneagent/oneagent-attribute-enrichment)
Custom problem fields: propagate fields from Davis events to problem records via Settings > Dynatrace Intelligence > Root cause analysis > Problem fields (see https://docs.dynatrace.com/docs/dynatrace-intelligence/problems-app/problems-app-custom-problem-field-examples).

If your data is enriched at the source, these filters keep your workflow within the simple workflow limit and no extra actions is needed.

Tagging strategy matters

The teams getting the most out of the platform have invested in enriching their data at the source, via OneAgent, Kubernetes labels, or OpenPipeline. Once that's in place, filtering in workflows, segments, and dashboards all uses the same fields. One source of truth, less manual work everywhere.

What's coming

we will add the ability to select Grail primary tags and fields directly in the problem trigger UI (no more raw DQL needed), and a way to copy filters from a segment into your trigger's filter query.
On delay: it's coming very soon, keep an eye on https://community.dynatrace.com/t5/Product-ideas/Delay-on-the-Davis-Problem-trigger-in-workflow/idi-p/252329 in the next couple of weeks.

I hope this helps,
Sonja