Classic alerting profiles and problem notifications are static channel configurations tied to management zones. Dynatrace workflows replace them with event-driven automation that supports conditional logic, branching, and native API integrations.
When upgrading alerting profiles and problem notifications to workflows, the goal should not be a simple one-to-one replication of your classic configuration, which may be the result of years of workarounds and constraints that no longer apply.
These best practices help you consolidate and redesign alerting for the latest platform model.
Before discussing migration strategy with stakeholders, run the alerting profile and problem notification assessment notebook and dashboard on your environment. The assessment quantifies the classic estate: total problem notifications, total alerting profiles, distribution by destination type, complexity per alerting profile, and consolidation opportunities.
The assessment notebook:
Use the assessment results to:
The most important structural difference between classic and Workflows is the consolidation model. In classic, every team needed a separate alerting profile/problem notification pair for each channel, because one alerting profile could select only one management zone. This created hundreds of nearly identical configurations.
In Workflows, the goal is to create one workflow per unique destination endpoint:
Use the decision tree from the assessment dashboard to identify consolidation opportunities before building workflows:
Classic alerting profile and problem notification counts that look large (hundreds of objects) often consolidate into a small number of workflows. The assessment dashboard shows the actual consolidation ratio; use this to justify the redesign to stakeholders before starting.
Select the workflow type based on what the notification destination requires:
| Destination type | Recommended workflow type | Why |
|---|---|---|
ChatOps channels (email, Slack, Teams) | Simple Workflow | Static payloads, simple routing, fits self-service model |
IT integrations (ServiceNow, PagerDuty, Jira, custom webhooks) | Standard Workflow | Requires dynamic fields, conditional logic, authentication, and structured payloads |
If a team sends to a primary IT integration and also sends a visibility copy to a ChatOps channel, evaluate whether the ChatOps copy can be a separate Simple Workflow or whether all actions should be combined in one Standard Workflow.
Configure production workflows to run under a dedicated service user rather than a human user account. Workflows running under human accounts break when the user leaves the organization or loses permissions.
Service users:
Assign the service user the minimum permissions required for the workflow to execute: automation:workflows:read, automation:workflows:run, and any connector-specific permissions the workflow actions require.
Any human user who needs to assign a service user to a workflow must have the iam:service-users:use permission. Ensure this permission is assigned before teams begin workflow configuration.
The Workflow Problem Trigger has two filter areas: a default filter (event category selection) and a custom filter (DQL expression). Both must be true for a workflow to fire; they are AND conditions, not alternatives.
If the default filter selects Availability and the custom filter includes matchesValue(event.category, "RESOURCE_CONTENTION"), no problem will ever trigger the workflow, because a problem belongs to only one category. The workflow appears correctly configured but silently never runs.
To avoid this
Note that the combined default and custom filter is hard-capped at 1,000 characters. This limit cannot be increased.
When routing problems to teams, use primary Grail tags (primary_tags.*) and dt.security_context as filter criteria instead of building long chains of entity-based conditions. Tags propagate from alerting events to the problem record automatically, making them available in the Workflow trigger without additional configuration.
A filter like matchesValue(primary_tags.team, "checkout") is shorter, more maintainable, and more reliable than a chain of entity name matchers. It also avoids consuming the 1,000-character trigger budget with conditions that could be collapsed into a single tag check.
Primary Grail fields and tags set on source entities are propagated automatically to alerting events and then to the problem record. For anomaly-detection-generated events from built-in OneAgent detection, define dt.alert_group or other routing fields as event properties in an OpenPipeline rule on the davis.events feed, since the built-in anomaly detection configuration does not support custom event properties directly.
Explore the other best practice for this stage, or return to Upgrade team-based & global alerting to continue your upgrade.