Triggering pipelines from Dynatrace problems

Dynatrace can post a Davis problem to any HTTP endpoint with a payload you define, which maps onto VectorStep’s generic source. On current Dynatrace this is a Workflow with a Problem trigger and an HTTP request action; on older or Managed installs it’s a Problem notification → Custom integration. Both are covered below.

Workflows (Dynatrace SaaS)

1. Allow the outbound call

Dynatrace checks every workflow HTTP call against a global allowlist of outbound hosts. Add your VectorStep host to it (in the tenant’s settings, under the allowed outbound connections / external requests page) before anything else, or the action fails before it sends.

2. Store the token in the credential vault

Create a Token credential holding a VectorStep token with the webhook role (see Securing a deployment). Dynatrace advises against a static Authorization header — header values are visible to anyone who can open the workflow monitor — so use the vault credential on the action instead of a header.

3. Build the workflow

1. Trigger: Problem trigger, state active (so closing a problem doesn’t start a second run), with the severity/category and affected-entity filters for the problems you want triaged. Enable Wait for root cause analysis so the payload isn’t sent half-formed.
2. Action: HTTP request.

Field	Value
Method	POST
URL	https://<your-vectorstep-host>/webhook?source=generic
Authentication	the Token credential from step 2
Header	Content-Type: application/json

Payload:

{
  "pipeline": "dynatrace-triage",
  "source": "dynatrace",
  "event": "{{ event()['event.status'] }}",
  "summary": "{{ event()['event.name'] }}",
  "idempotency_key": "{{ event()['display_id'] }}:{{ event()['event.status'] }}",
  "data": {
    "problem_id": "{{ event()['display_id'] }}",
    "category": "{{ event()['event.category'] }}",
    "affected_entities": "{{ event()['affected_entity_ids'] }}",
    "root_cause_entity": "{{ event()['root_cause_entity_name'] }}"
  }
}

Confirm the field names on your tenant

event() returns the whole problem event, and the exact fields depend on the Dynatrace version and the event category. The names above are the common ones but aren’t guaranteed. Open a notebook and run fetch dt.davis.problems | limit 1 to see the real fields, then adjust the payload to match. A misspelled field renders as empty, not as an error, so test before relying on it.

4. Dedup key

display_id (the P-… identifier shown in the UI) is stable for the life of a problem, so repeat updates to the same problem are absorbed. Appending the status keeps the closed notification distinct from the active one, which matters if you widen the trigger to active or closed. Drop idempotency_key to disable dedup.

Legacy: Problem notification (Managed / older installs)

Settings → Integration → Problem notifications → Custom integration.

Field	Value
Webhook URL	https://<your-vectorstep-host>/webhook?source=generic
Additional HTTP headers	Authorization: Bearer <token>
Custom payload	below

{
  "pipeline": "dynatrace-triage",
  "source": "dynatrace",
  "event": "{State}",
  "summary": "{ProblemTitle}",
  "idempotency_key": "{PID}:{State}",
  "data": {
    "problem_id": "{ProblemID}",
    "impact": "{ProblemImpact}",
    "impacted_entity": "{ImpactedEntity}",
    "tags": "{Tags}"
  }
}

Dynatrace’s placeholders are substituted as text, and the JSON-typed ones ({ImpactedEntities}, {ProblemDetailsJSON}) must be unquoted to stay valid JSON, while string ones must be quoted. The payload above uses only string placeholders for that reason; pull in the JSON-typed ones only if a prompt needs them, unquoted, and expect data to then nest.

Test it

Trigger the workflow manually from the Workflows app (Run), or send the shape by hand:

curl -X POST "https://<your-vectorstep-host>/webhook?source=generic&allow_testing=true" \
  -H "Authorization: Bearer $VECTORSTEP_WEBHOOK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"pipeline":"dynatrace-triage","source":"dynatrace","summary":"Failure rate increase",
       "idempotency_key":"P-12345:ACTIVE","data":{"problem_id":"P-12345"}}'

allow_testing=true is only needed while the pipeline is stage: testing. A workflow HTTP action fails the task on non-2xx by default, so a 401 (wrong/expired token) or 422 (wrong pipeline name) shows up directly in the workflow execution log.

Using the data in a prompt

context_template:
  include:
    - summary
    - metadata

prompt_template: |
  Dynatrace problem {{metadata.problem_id}}: {{summary}}.
  Affected: {{metadata.affected_entities | default("unknown")}}.

Severity isn’t a first-class field with the generic source, so pass it in data if the pipeline needs it. Alternatively, filter by severity in the Dynatrace trigger itself so only the problems you care about are ever sent.

Investigating back in Dynatrace

This guide is inbound only. For the pipeline’s agent to query Dynatrace during the investigation (entities, topology, logs, problems), give it Dynatrace’s own MCP server rather than building a custom integration — see MCP servers and Choosing an executor for external calls.