Event triggers for workflows

• Latest Dynatrace
• Reference
• 6-min read
• Updated on Jul 27, 2026

Dynatrace Workflows supports three event-based trigger types that start when events flow through OpenPipeline. Choose the type that matches your event source and the level of granularity you need.

Choose a trigger type

Problem trigger

Problems are created by Dynatrace Intelligence by correlating anomalies and their root causes across your environment. The Problem trigger starts a workflow when a problem opens, changes, or resolves. The event source is Davis problems.

To browse past occurrences, explore available fields, and test filter conditions before configuring the trigger, run this query in a notebook:

fetch dt.davis.problems

The trigger applies its own deduplication logic to decide when to start. To inspect the raw event stream the trigger evaluates, use:

fetch events
| filter event.kind == "DAVIS_PROBLEM"

Configuration

Without Updates enabled, the trigger starts once per state transition and does not start again as the problem evolves.

Under Advanced options:

Trigger delay

By default, the Problem trigger starts as soon as a matching problem becomes active. The Minimum duration option postpones the trigger until the problem has been open for at least the configured duration.

The allowed values are (in minutes):

The delay is based on dt.duration_marker, a field set by Dynatrace Intelligence that accumulates from the moment the problem was first created.

The trigger starts once when the threshold is crossed on the active phase and, if selected, also once on closure. A problem that is closed before ever reaching the configured threshold doesn't produce a trigger.

Re-trigger on field changes

Problems evolve over time as new Davis events are detected and merged into an existing problem record, which can change fields such as severity or affected entities. The Updates option re-triggers the workflow when the value of a selected problem field changes. Each distinct combination of selected field values triggers the workflow at most once; it won't start again unless the values change to a new combination.

For example, if you select severity for Updates, the trigger starts when severity changes from MEDIUM to HIGH. If severity escalates to CRITICAL, the trigger starts again because the field value changed to a new combination.

The affected entities field tracks the union of affected_entity_ids and smartscape.affected_entities. A change to either underlying field counts as a change to affected entities.

Davis event trigger

Dynatrace Intelligence generates alerts, stored as Davis events in Grail, during anomaly detection and analysis. Davis events are more granular than problems: a single problem can group multiple Davis events as conditions evolve (for example, a resource saturation event followed by a service degradation event). The Davis event trigger lets you react to a specific Davis event rather than the problem as a whole.

The event source is Davis events. To browse past occurrences, explore available fields, and test filter conditions before configuring the trigger, run this query in a notebook:

fetch dt.davis.events

The trigger applies its own deduplication logic to decide when to start. To inspect the raw event stream the trigger evaluates, use:

fetch events
| filter event.kind == "DAVIS_EVENT"

Configuration

Event trigger

The Event trigger starts a workflow for each event that matches a DQL matcher expression. Use it when no built-in trigger type covers your event source or when you need a fully custom filter condition.

Event type

Select which event type to react on:

Filter query

In Filter query, narrow down which events start the trigger using DQL matcher syntax. The filter query is part of the total matching expression, which is limited to 1,000 characters across all trigger fields.

Example 1: Match a specific business event type.

event.type == "com.example.order.completed"

Example 2: Match security events with a specific status.

event.kind == "SECURITY_EVENT" and vulnerability.resolution.status == "OPEN"

Optional Select Query past events to estimate how many events match your filter in your environment before saving the trigger.

Use event data in workflow tasks

When a workflow is triggered by an event, the full event payload is available to all downstream tasks. Reference it with the event() expression.

For example, event()["event.type"] returns the type of the triggering event. You can use any field from the event payload to pass context to actions, build conditions, or personalize notifications.

For manual runs during development, Workflows pre-fills the event context from the last successful execution and lets you adjust it before running.

Limits

Filter expression size: The full matching expression compiled from all trigger fields (entity filters, event name, and any Additional custom filter query) is limited to 1,000 characters. Saving a trigger whose compiled expression exceeds this limit or contains invalid DQL returns a validation error.

DQL matcher syntax: Event trigger filter expressions use DQL matcher syntax. Each event is evaluated individually as it enters OpenPipeline; aggregation functions and multi-event queries are not supported.

Execution rate: Each workflow is limited to 1,000 event-triggered executions per hour. If this limit is exceeded, executions are throttled (HTTP 429) for up to one hour. If it's exceeded three times within seven days, the trigger is automatically deactivated.

Both a throttle event and a deactivation are flagged in the Workflows overview and can be filtered on.

Use Query past events in the trigger configuration to estimate expected event volume and avoid hitting the limit before deploying.

Permissions