Classic security alerting profiles are managed centrally and tied to management zones. Latest Dynatrace security notifications are fully orchestrated by Workflows, which provide granular trigger conditions, broader external tool integration, and greater flexibility in action logic. These best practices help you migrate classic security alerting profiles to equivalent Workflow-based notifications.
In Dynatrace Classic, security notifications required two objects: a security alerting profile (for filter conditions) and a connected service (for delivery). In Latest Dynatrace, a single Workflow replaces both.
The alerting profile conditions become the Workflow trigger combined with a DQL filter. The connected service becomes a Workflow action using a Workflow Connector or a built-in action.
Classic trigger conditions and their Workflow equivalents:
Vulnerability (re)opened: use an event-based trigger with DQL filter:
event.category == "VULNERABILITY_MANAGEMENT" ANDevent.type == "VULNERABILITY_STATUS_CHANGE_EVENT" ANDevent.level == "ENTITY" ANDvulnerability.resolution.status == "OPEN" ANDvulnerability.mute.status != "MUTED"
Attack blocked: use an event-based trigger with DQL filter:
product.vendor == "Dynatrace" ANDevent.type == "DETECTION_FINDING" ANDfinding.action == "Blocked"
New management zone affected: this classic condition has no direct equivalent because management zones are removed in Latest Dynatrace. Replace it with field-based conditions using primary Grail fields, dt.security_context, or primary Grail tags.
If you opt into Phase 3 of Latest Dynatrace, migrating security alerting profiles to Workflows is mandatory; classic security alerting profiles will not function after the Phase 3 transition.
Latest Dynatrace security Workflows support two trigger approaches:
Event-based trigger: fires immediately each time a new security event is detected and stored in Grail. Use this approach when you need real-time alerting as soon as a vulnerability or attack event appears. Simple Workflows can only use event-based triggers.
Time-interval trigger: runs the Workflow on a schedule (for example, every hour) and includes a DQL query action to retrieve security events over the past time period. Use this approach when you want to batch notifications, deduplicate alerts, or control the number of Workflow executions in large environments with high event volumes.
Choose the event-based trigger for critical, high-priority alerts where immediate notification is required. Choose the time-interval trigger for digest-style notifications or when execution costs require control.
If you use an event-based trigger, apply specific DQL filter conditions to limit which security events fire the Workflow. Without proper filtering, large environments with many detections generate a high volume of Workflow executions, which increases automation consumption costs.
Configure security notification Workflows to run under a dedicated service user rather than a human user account. This is especially important for security Workflows, where the execution identity affects access to security event data.
The identity used to create and run the Workflow must have at minimum storage:security.events:read permission. Assign this permission to both the human user creating the Workflow and the service user the Workflow runs as.
Review the Dynatrace Workflow permissions and security documentation for the complete list of permissions required per Workflow action type.
The classic "New management zone affected" condition scoped security notifications by management zone. Management zones are not available in Latest Dynatrace. Replace management zone scoping with Grail record-based field filters.
Recommended scoping approaches:
dt.host_group.id or k8s.cluster.name to scope by infrastructure boundary. Check that the Primary Grail Field is available for the specific security event data type before using it.dt.security_context: use custom metadata enrichment to set dt.security_context on security events via OpenPipeline, then filter by it in the Workflow trigger.primary_tags.app or primary_tags.environment to scope by application or environment.For example, to scope to security events targeting production assets:
| filter matchesPhrase(k8s.cluster.name, "*PROD")
Or using dt.security_context:
| filter matchesPhrase(dt.security_context, "*PROD")
Avoid building complex security notification Workflows with many conditional branches and multiple action types. Complex workflows are harder to troubleshoot and maintain.
Design principles for security notification Workflows:
When designing the Workflow, verify the estimated number of executions per day and the associated automation consumption cost before enabling it in production. This is especially important for event-based triggers in environments with high security event volumes.
Explore the other best practice for this stage, or return to Upgrade team-based & global alerting to continue your upgrade.