Dynatrace

Dynatrace can notify OpsFusion two ways. The basic Custom integration notification only does flat placeholder substitution — Dynatrace’s own support docs confirm “you cannot write any kind of logic in webhook payloads” there, so it needs one notification config per problem state. Workflows, Dynatrace’s automation product, is different: it uses a real Jinja templating engine (with {% if %}/{% elif %}/{% else %} blocks and inline ternary expressions), so a single workflow can compute status dynamically from the triggering event instead of requiring separate configs.

See API Overview for authentication and finding your Account ID/Team ID.

Configure the Webhook in Dynatrace

Recommended: Workflows (one config, dynamic status)

1. In Dynatrace, go to Workflows and create a new workflow.
2. Set the trigger to a Davis problem trigger.
3. Add an HTTP request action: method POST, URL https://api.opsfusion.cloud/v1/account/YOUR_ACCOUNT_ID/push/alert, header Authorization: YOUR_API_KEY.
4. In the action’s payload field, use the Jinja template below — it reads the triggering problem’s event.status field to set status inline, so open and resolved events both flow through the same workflow.

Simpler alternative: Custom integration notification

If you don’t need dynamic status in one place, the classic path still works: Settings → Notifications → Custom integration, with a Custom payload field using flat placeholders ({ProblemTitle}, {ProblemID}, {State}, etc.). Since there’s no logic available in that field, you’ll need one notification config for problem-opened and another for problem-resolved, each with status hardcoded.

Payload Template

Workflow (Jinja, dynamic status):

{
  "teamId": YOUR_TEAM_ID,
  "title": "{{ event()['event.name'] }}",
  "description": "{{ event()['event.status'] }}",
  "severity": 2,
  "status": {{ 1 if event()['event.status'] == 'OPEN' else 3 }}
}

event()['event.status'] returns OPEN/RESOLVED for a Davis problem trigger — confirmed via Dynatrace’s Workflows reference docs. The ternary ({{ a if cond else b }}) is standard Jinja syntax; Dynatrace’s {% if %}/{% elif %}/{% else %} block form works the same way if you’d rather branch the whole object instead of just the status value. There’s no confirmed single field for problem severity in the trigger’s event data — check your workflow’s available fields (Dynatrace suggests using Notebooks to inspect the raw event payload) before trying to map it inline; hardcoding severity per workflow is the safe default shown above.

Custom integration (flat placeholders, one config per state):

{
  "teamId": YOUR_TEAM_ID,
  "title": "{ProblemTitle}",
  "description": "{ProblemDetailsText}",
  "severity": 2,
  "status": 1,
  "labels": {
    "problem_id": "{ProblemID}"
  }
}

Dynatrace inserts placeholders unescaped, so anything that’s already valid JSON (like {ImpactedEntities}, an array) should be dropped in without surrounding quotes. {State} returns text (OPEN/RESOLVED), not an integer, so — unlike the Workflow path — it can’t be converted inline here; hardcode status per notification config instead (1 for the problem-opened config, 3 for the problem-resolved one).

Field Mapping

OpsFusion field	Dynatrace source (Workflow)	Dynatrace source (Custom integration)
teamId	Hardcoded per workflow	Hardcoded per integration
title	event()['event.name']	{ProblemTitle}
description	event()['event.status'] (or another field found via Notebooks)	{ProblemDetailsText} (or {ProblemDetailsHTML}/{ProblemDetailsJSON})
severity	Hardcoded (no confirmed single severity field on the trigger event)	Map from {ProblemSeverity} (e.g. AVAILABILITY/ERROR → 1, PERFORMANCE → 2, RESOURCE_CONTENTION → 3) — set per integration
status	Computed inline from event()['event.status'] (OPEN → 1, else 3)	Hardcoded per notification config, based on problem open (1) vs. resolved (3)
labels	event()['event.id']	{ProblemID}, {Tags}

Troubleshooting

• Payload rejected as invalid JSON (Custom integration): double check placeholders that already return JSON (like {ImpactedEntities}) aren’t wrapped in extra quotes.
• Alerts never resolve in OpsFusion (Custom integration): confirm you have a notification configured for the problem-resolved event with status: 3, not just one for problem-opened.
• Workflow’s HTTP request fails or the Jinja expression errors: check the workflow’s execution log — it shows the rendered payload, which makes it easy to spot a wrong field name (e.g. event.status vs. a differently-named field for a non-problem trigger type).
• 403 from OpsFusion: verify the Authorization header is saved on the notification config or workflow action — Dynatrace doesn’t always show custom headers by default in the summary view, so re-open the config to confirm.

Support

For integration support:

• Email: support@opsfusion.cloud
• See Send Alerts for the full API reference