Upgrade from Classic problem notification to simple workflows
- Latest Dynatrace
- Upgrade guide
- 10-min read
This guide shows you how to replace the Dynatrace Classic configuration to route problems to external systems using a combination of alerting profiles and problem notifications with the new concept of simple workflows.
A simple workflow has a trigger that performs the filtering and an action that performs the delivery. It covers mapping every alerting profile filter type, mapping Dynatrace Classic notification placeholders to Davis AI problem record fields, and the step-by-step upgrade of one alerting profile and problem notification pair into a single workflow.
Why upgrade?
In Dynatrace Classic, an alerting profile is the routing unit, and a problem notification must reference exactly one alerting profile. Because an alerting profile can also select only one management zone, teams end up creating a separate alerting profile and problem notification pair for nearly every combination of scope, severity, and destination. Large environments routinely run hundreds of pairs that differ in one field.
These configurations are also environment-global. A user can't subscribe to problem notification emails without admin rights, as this requires creating a new global settings object.
Latest Dynatrace changes this in various ways:
-
Filtering moves into the workflow trigger.
A workflow's Problem trigger filters problems directly with DQL matchers on the problem. There is no separate filter object to create, name, and maintain, nor is there a one-management-zone-per-profile constraint.
-
One destination, one workflow.
While Dynatrace Classic required one problem notification per alerting profile, a single workflow trigger can encapsulate the combined filter logic of multiple alerting profiles. Pairs that share a destination are in a single configuration.
-
Every delivery is auditable.
Workflow executions are recorded as Dynatrace system events in Grail. Classic notification failures were not recorded.
Beyond setting up notifications, 
Workflows can enrich, branch, and remediate.
For AI-driven scenarios, agentic workflows let Dynatrace Intelligence assess a situation and act automatically, summarizing a problem, computing a score, or triggering remediation without manual intervention.
Use the new Davis event report fields
These Davis event report fields have no Classic {Placeholder} counterpart and are frequently the reason to move:
| Field | Value |
|---|---|
| Estimated affected users for the worst-hit application |
| How long the problem has been open, as a stepped threshold |
| Whether the problem falls inside a maintenance window |
| The Davis events contributing to this problem |
| Access-scoping context propagated from the affected entities |
| Cost Allocation, propagated from the affected entities |
| Final duration once resolved |
|
|
| Root cause node — |
For the full field reference, see Davis ID in the Semantic Dictionary.
root_cause_entity_id and root_cause_entity_name are deprecated in favor of root_cause.smartscape_entity, and affected_entity_ids in favor of smartscape.affected_entities. Build new payloads against the Smartscape fields.
Primary Grail fields and tags (primary_tags.*), dt.security_context, and the Cost Allocation fields are automatically propagated from the alerting events into the problem record.
You can filter and template on them directly on the problem; no join back to dt.davis.events is needed.
Values accumulate across every event grouped under the problem.
If two affected services carry primary_tags.team with different values, the problem holds both.
There is no way to determine which value came from which entity.
The problem carries the deduplicated union.
What will you do?
In this guide, you'll learn how to upgrade Dynatrace Classic notifications and alerts to simple workflows.
Before you begin
Prerequisites
- An active Dynatrace Platform Subscription (DPS) license.
- Permission to create workflows in the target environment.
- Read access to the events that the trigger reacts to. For more information, see trigger permissions.
New concepts
The following concepts are introduced in Latest Dynatrace.
- Workflows and simple workflows
- Event triggers: the Problem trigger replaces the alerting profile
- Connectors and actions replace the notification channel
- Jinja expressions replace the Dynatrace Classic
{Placeholder}syntax in payloads - EdgeConnect makes apps and workflows interact securely with your systems
For an overview of how alerting, problem detection, and Workflows fit together in Latest Dynatrace, see Alerting and notifications.
How to upgrade to simple workflows
List current notifications and alerts
Audit your existing alerting profile and problem notification pairs to decide what to delete, consolidate, and upgrade. Don't upgrade the notifications and alerts one-to-one.
Before creating anything, list your existing pairs and answer three questions:
- Which notifications are disabled, or enabled but have not fired recently? Delete them; don't upgrade them.
- Which notifications point at the same destination, the same Slack channel, the same webhook URL, the same ServiceNow instance? Collect those into one workflow.
- Which alerting profiles are attached to more than one notification? Each becomes one workflow with one action per destination.
You can read the classic configuration through the Settings API schemas builtin:problem.notifications, builtin:alerting.profile, and builtin:management-zones.
You now have a categorized inventory of your existing alerting profile and problem notification pairs: which to delete, which to consolidate into fewer workflows, and which to upgrade. Keep this list at hand for the following steps.
Set up workflow and Problem trigger to match alerts and notifications
Create a simple workflow, select the Problem trigger, and set which problem states activate it.
-
Go to
Workflows. -
Select the Problem trigger.
-
Set the Problem state to match the Dynatrace Classic behavior you're replacing. The table below maps the new Problem state to the Dynatrace Classic behavior.
Classic behavior Problem trigger Event state Notify on open only
activeNotify on open and resolve
active or closedNotify on resolve only
closed -
From the Event category drop-down, only select the event categories you need. Each selection consumes a portion of the shared 1,000-character filter budget.
-
In the Initial root cause analysis section, enable Wait for root cause analysis under Advanced options. This is the closest equivalent to Dynatrace Classic timing: Dynatrace Classic notifications were sent when analysis had progressed far enough to warrant follow-up actions. Without it, your workflow may fire on a partially assembled problem.
The Problem state reflects your Dynatrace Classic behavior, your event categories are selected, and Wait for root cause analysis is enabled under Advanced options.
For best practices, see Best practices for upgrading to simple workflows.
Validate workflow Problem trigger
Before adding the action, confirm that your trigger filter matches problems in your environment.
Select Query past events in the trigger. It reports how many events would have matched over the last hour, day, and seven days.
- Non-zero results in at least one time window confirm the trigger is correctly scoped and ready for the action step.
- A result of zero across all three windows in a busy environment almost always means your default category selection and your custom filter contradict each other. See Why does my workflow never trigger? in the FAQ.
Configure problem notification using a workflow action
Problem notifications alone rarely cover all your integration requirements.
To route problems to standard third-party tools, such as ServiceNow, Jira, PagerDuty, or Slack, or a generic HTTP webhook, use Workflows Connectors.
For help mapping Dynatrace Classic integrations with Workflows Connectors, see the table below.
Build the payload with Jinja expressions over the problem record; use the placeholder mapping table to translate your existing {Placeholders}.
The following table maps each Dynatrace Classic integration to its workflow equivalent.
| Dynatrace Classic integrations | Workflows Connector equivalent |
|---|---|
Ansible | |
Custom integration (generic webhook) | |
Jira | |
PagerDuty | |
ServiceNow | |
Slack | |
Microsoft Teams | |
Opsgenie | Opsgenie is being retired by Atlassian and replaced by Jira Service Management (JSM). No official JSM connector is available yet. Use HTTP Request. |
Trello | No dedicated connector. Use HTTP Request. |
VictorOps | No dedicated connector. Use HTTP Request. |
xMatters | No dedicated connector. Use HTTP Request. |
Connectors go beyond notifications; you can also use them to trigger automated actions and remediation in Kubernetes, AWS, Azure, GitHub, GitLab, and Jenkins.
You now have a workflow action configured to deliver problem data to your target system.
The action replaces the Dynatrace Classic problem notification channel, and the payload uses Jinja expressions translated from your existing {Placeholders} using the mapping table.
Select the right workflow type
The table below shows differences between simple and standard workflows.
| Simple workflow | Standard workflow | |
|---|---|---|
Structure | One trigger, one task | Multiple tasks, branching, loops |
Run JavaScript / Run workflow | Not available | Available |
Workflow-hour consumption | None | Billed as Automation Workflow |
Fits | Send problem data as-is to one channel | Enrich, transform, branch, orchestrate |
For example:
- Use a simple workflow whenever the destination accepts the problem record as-is.
- Choose the standard workflow when the payload needs conditional logic, when you need to call an external API for enrichment, or when one filter must fan out to several destinations in a single configuration.
On cost: Simple workflows don't consume workflow hours, but each task execution counts as one AppEngine function invocation, and is billed as Automation Workflow. For typical notification volumes, the cost is low but worth estimating before you design a workflow that triggers many executions per problem.
You've identified whether a simple or standard workflow fits your use case and understand the cost implications before activating.
Verify workflow delivers the right notifications
Before decommissioning the Dynatrace Classic pair, confirm the new workflow delivers correctly.
- Test the workflow end-to-end and run the workflow alongside the Dynatrace Classic notification before changing over.
- Run the workflow manually against a real problem record before activating it.
Workflows pre-fills the event context from the last successful execution.
Workflow executions are recorded as Dynatrace system events in Grail.
With storage:system:read access, query the trigger history:
fetch dt.system.events| filter event.kind == "WORKFLOW_EVENT" and event.provider == "AUTOMATION_ENGINE" and event.type == "WORKFLOW_EXECUTION"| summarize count = count(), by:{dt.automation_engine.workflow.title}| sort count desc
Execution logs for simple workflows are visible only for a limited time, and the Executions page does not display their history. The Grail query above is the reliable long-term record. See Monitor workflow executions.
For more information, see AutomationEngine workflow execution event.
Leave the Dynatrace Classic notification enabled for one full business cycle and compare volumes on both sides. Disable the Dynatrace Classic pair only once the counts match. Delete it once you're confident you're getting the right notification.
For more information on running a workflow, see Monitor workflow executions.
The Dynatrace Classic alerting profile and problem notification pair is disabled, your workflow is active, and delivery volumes match. Your upgrade is complete.
Best practices
-
Consolidate by destination, not by filter.
The Dynatrace Classic model required a single profile per notification. This no longer applies. Hundreds of alerting profiles and problem notification pairs pointing to the same Slack channel become a single workflow, not hundreds.
-
Trigger on problems, not on Davis events.
Dynatrace Intelligence groups related alerts into one problem. Triggering on raw events bypasses that grouping and floods the channel. Use the Davis event trigger only when you genuinely need per-alert granularity.
-
Never leave a trigger unfiltered.
A workflow with no filter notifies on every problem in the environment. The minimum filtering is by category and severity.
-
Enable Wait for root cause analysis.
Without this option enabled, the workflow can trigger on a problem whose root cause and affected entities are still being assembled.
-
Pair every open notification with a close notification.
Responders need to know when the incident is closed. Set the Problem state to
active or closed, or build a second workflow filteringevent.status == "CLOSED", if it's suitable for the use case. -
Include the problem link.
Use
{{ problem_link() }}so recipients reach the problem with a single selection. -
Do not filter on
root_cause.smartscape_entity.Dynatrace Intelligence does not populate a root cause for every problem, particularly early in the lifecycle or for externally ingested events. A root-cause condition silently drops those problems. Filter on tags or affected entities instead.
-
Prefer tags over long filter chains.
Tagging entities with meaningful metadata and filtering on
primary_tags.*is more maintainable than chaining entity conditions, and it keeps the query within the 1,000-character budget. -
Run a service user as the workflow actor.
A workflow whose actor is a named user stops working when that person leaves or loses a permission. Service users have their own scoped permissions and are built for non-interactive execution. For more information, see Workflow security.
-
Split workflows when teams need isolation, even if the destination is identical.
A shared workflow is a shared control plane. Anyone with write access can change the routing for everyone using it.
-
Test against a low-impact source first.
Validate the full path end-to-end before you connect production alerts to on-call systems.
FAQ
Do I need to upgrade all my alerting profiles?
Almost certainly not.
Before designing anything, audit what is in use:
- Disabled notifications: Delete, don't upgrade.
- Enabled but dormant: Notifications that haven't fired in 90 days are decommissioning candidates.
- Shared destinations: Notifications pointing at the same endpoint collapse into one workflow.
- Profiles with multiple notifications attached: One workflow, one action per destination.
The Dynatrace Classic setup reflects constraints that no longer exist: one management zone per profile, one profile per notification, and separate profiles created purely to vary the delay. Reproducing the Dynatrace Classic estate one-to-one carries all those constraints forward, inflates your workflow count, and makes long-term maintenance harder.
Why does my workflow never trigger?
If Query past events returns zero matches across all time windows in an environment that is definitely producing problems, the usual cause is a contradiction between the trigger's default filters and the Additional custom filter.
These are AND conditions, not alternatives.
A problem must satisfy both.
The UI requires you to select at least one event category, but it doesn't check that the custom filter is consistent with that selection.
Two failure modes:
-
Direct conflict. The default filter has Availability selected; the custom filter contains
matchesValue(event.category, "RESOURCE_CONTENTION"). A problem belongs to one category, so both conditions can't be true simultaneously. Result: zero executions, no error, a workflow that looks correctly configured, and never runs. -
Silent scope reduction. The default filter has Error and Availability selected; the custom filter is constrained to
ERROR. Availability problems are excluded entirely. The Availability selection consumes part of the 1,000-character budget without effect.
The rule decides which categories you need before writing any custom filter, and select exactly those.
To get the workflow to trigger, you have two options:
- Bind category to condition in the custom filter, in which case the default selection must contain exactly the categories the custom filter references, nothing more.
- Or keep the custom filter category-agnostic and let the default selection handle all category scoping. This is simpler and uses fewer characters.
How do I map my problem notification placeholders?
Classic notifications used a fixed set of {Placeholders}.
In a workflow, you reference Grail problem record fields through Jinja instead, for example, {{ event()["event.name"] }}.
Because the problem structure changed, the mapping is no longer one-to-one.
| Classic placeholder | Grail problem field | Notes |
|---|---|---|
|
|
|
|
| For example, |
|
| |
|
| |
|
| Also consider existing field |
|
| Lists all impact levels observed across the problem's events: Application, Environment, Infrastructure, Services, Synthetic |
|
| Record array; each element has |
|
| Read |
|
|
|
|
| Markdown. Content differs from Dynatrace Classic. |
| Not supported | Use |
|
| Exposes the full record. Different structure and content from Dynatrace Classic. For more information, see Can I send out a Dynatrace Classic JSON payload? |
|
| Evaluates only in workflows with a Davis problem trigger |
|
| Format differs from Dynatrace Classic |
Can I also send event details of a given Problem?
Not in the same payload. The two triggers expose different records:
- Problem trigger: Problem record fields only.
- Davis event trigger: Individual event record fields only.
This is deliberate.
ProblemDetailsJSON and ProblemDetailsJSONv2 embedded every contributing event.
For a large problem, this produced payloads of 10 MB or more, which receiving systems struggled to process.
If you need the contributing events, dt.davis.event_ids on the problem record gives you the IDs to query dt.davis.events for exactly the events you want.
The Davis event trigger also enables automation on non-problem events, such as deployments, configuration changes, and informational signals, without surfacing a problem to your operations team.
Can I send out a Dynatrace Classic JSON payload?
No. ProblemDetailsJSON and ProblemDetailsJSONv2 can't be reproduced from a workflow. The Grail problem record has a different structure and different contents.
If your receiving system parses the Dynatrace Classic DTO, you have two options:
- Adapt the receiver to the Grail problem record.
Send
{{ event() | to_json }}and map fields on the receiving side. - Build the payload explicitly in the action, naming the fields the receiver expects and populating them from Grail fields using the mapping table above. A standard workflow provides conditional logic when the shape needs to vary.
What are the workflow limits?
For current limits, see Event trigger limits.
Two limits matter for notification workflows.
-
Filter expression size: 1,000 characters. Every trigger field compiles into one matching expression: entity filters, event name, category selections, and your Additional custom filter all share the same budget. Saving a trigger that exceeds it returns a validation error.
This is an OpenPipeline DQL matcher constraint. If you're hitting it, restructure rather than trim: tag your entities following the tagging strategy and filter on
primary_tags.*, or define an OpenPipeline processor that adds a calculated property you can match on in one short condition. -
Execution rate: 1,000 event-triggered executions per hour, per workflow. Exceeding it throttles further executions with an HTTP 429 response for up to one hour. Throttling is flagged in the
Workflows overview and can be filtered on.
The trigger is not automatically deactivated when the limit is reached repeatedly.
Use Query past events in trigger configuration to estimate volume before deploying.
Environment limits are 10,000 workflows per customer environment and 100 per trial environment.
Higher execution limits can be requested via a support ticket, along with your use case. Bring current peak execution figures and expected growth, as requests are reviewed against actual demand.
How do I prevent notifications during a maintenance window?
You can prevent notifications during a maintenance window by editing the Problem trigger, and adding the following DQL statement to the Additional custom filter field:
maintenance.is_under_maintenance == false
This filters out problems that were open during a maintenance window. For more details, see Maintenance windows.
Are alerting profiles deprecated?
Alerting profiles and problem notifications are Dynatrace Classic. They continue to work and are not being removed on a published schedule, but they'll not receive new capabilities. The delay, update, and severity capabilities described in this guide exist only on the workflow trigger.
The labels.alerting_profile field on the problem record is deprecated.
If you have used it to identify which profile matched a problem, move on to filtering directly on problem properties.