Dynatrace Intelligence integration for
Workflows allows you to use agentic workflow actions to actively react to changes and analyze real-time data in your environment by using Dynatrace agentic tools.
The Run agent workflow action is audience-agnostic. This means that the Run agent is customizable and can be adjusted to your needs. By using this action, you can use ready-made agents and customize the investigation by specifying:
To use Dynatrace Intelligence, you need to ensure that your DPS license includes AI Units capabilities.
To use the Dynatrace Intelligence agentic AI workflow action, ensure that you have the following permissions:
ai:operator:executemcp-gateway:servers:invokemcp-gateway:servers:readdocument:documents:readDepending on the tools you use, you might need additional permissions. For more information about tool-specific permissions, see Server and server tools.
Starting with Dynatrace version 1.347+, using Dynatrace Intelligence AI outside the Assist UI,
Dashboards, and
Notebooks is subject to license consumption according to your existing licensing agreement and requires a DPS license that includes AI Units capabilities.
If you are subscribed to any non-DPS licensing model or missing the required capability, you are no longer able to use agentic AI workflow actions.
Standard usage limits for Agentic and generative AI are also applied to Dynatrace Intelligence:
| Item | Maximum limit |
|---|---|
Individual user requests | 25 requests per 15 minutes |
All user requests across the environment | 60 requests per 15 minutes |
Duration of request to operator processing | 120 seconds |
If you schedule the automatic workflow execution to run frequently, all other Dynatrace Intelligence agentic and generative AI functionality might be throttled due to reaching the request limit. If you do run into the usage limit, please reach out to your CSM.
To create a workflow with the Run agent action
Workflows.Dynatrace Intelligence into the search field or select Dynatrace Intelligence > Run agent.SRE Agent from Ready-made agents.
Once you select an agent, you're able to review its functionality in Agent description.
You can enter a maximum of 10,000 characters in this field.
You can enter a maximum of 200,000 characters in this field.
You can configure the SRE Agent to investigate new triggered problems across logs, traces, and metrics and automatically add problem annotations with the investigation results.
Workflows.active.Availability and Error).dt.davis.is_duplicate == false to avoid overalerting.SRE Agent from Ready-made agents.
Once you select an agent, you're able to review its functionality in Agent description.
Run a root cause analysis for problem with the id {{event()["display_id"]}}.Work outwards from the affected entities: their error and warning logs, the distributed traces of any service among them for the failing or slow span, the triggering metric's own time series where a threshold fired rather than the alert description alone, and how often this same alert name has already fired against the same entity in the last 24-48h.Judge what kind of problem this is and whether it needs attention. Synthetic, deliberately generated and test-origin alerts are noise and should be called out as such - a high, steady recurrence with no correlating logs is itself evidence of that. Where the evidence does not support a call either way, say so plainly and name what you checked, rather than offering a plausible guess.
Answer in this structure:**Verdict** - one short, self-contained statement the reader can act on: what kind of problem this is, what is happening, to which entity, and since when. One sentence.## Root Cause ReasoningName the root cause, then reason it through: the chain from that cause to the symptom the alert fired on, and why it happened when it did. Two to four sentences. Follow the system's causality, not your own train of thought.## RecommendationsThe remediating measures you recommend.## Evidence and findingsThe facts a reader needs to accept or challenge the verdict - for each, the entity it concerns, the value or timestamp behind it, and a link to its source. Whatever shaped the verdict belongs here: recurrence counts with the related problem ids, or a shared entity, cluster, namespace, naming, tag or alerting profile.## Additional instructions- Your response is parsed programmatically. It MUST start with the exact three characters `**V` (the opening of `**Verdict**`) as the very first characters of your output - no text, whitespace, reasoning, or planning statement may come before it. A response that starts with anything else fails this task outright.- Do not include any planning, confirmation, or narration sentence anywhere in the response - not before the verdict, not between sections. Examples of what this bans, verbatim: "I now have all the evidence needed", "Let me compile the findings", "The recurrence pattern is definitive", "Writing the report". If a sentence like this forms in your reasoning, discard it before responding - it must never reach the output.- Never comment on your own evidence. Drop phrases such as "I have all the data I need" or "the recurrence data is clear".- Never name your tools. No mention of the queries, files, commands or search results behind a finding.- Ground every finding in data you retrieved. Where you cannot point to that data, do not make the statement.- State every fact once, in the section the structure assigns to it.- Use at most 20 tool calls; the backend refuses more and a run that reaches the limit returns nothing at all, so stop investigating and write the report while calls remain - a short report with an open verdict beats running out.- Link source data with relative paths so it resolves on the current environment: an entity as [CheckDestination](/ui/entity/SERVICE-907DC3F55716BCC9), a problem as [P-2609087](/ui/apps/dynatrace.davis.problems/problem/P-2609087), logs as [Logs](/ui/apps/dynatrace.logs), Kubernetes as [Kubernetes](/ui/apps/dynatrace.kubernetes).- Where you reference an alert configuration, link where it is changed rather than the alert itself: [centralized alert management](/ui/apps/dynatrace.settings/settings/alerts).- Never invent an ID, and never write an absolute URL containing a host name. Only link an ID you actually retrieved.- Keep tables to three columns at most, and use lists, code blocks and iconography to make findings scannable.- Keep the report under 800 words.- Close with a finished report. Never offer to continue and never ask a question back; the report is read after the run has ended.
You can enter a maximum of 10,000 characters in this field.
You can enter a maximum of 200,000 characters in this field.
{{event()["event.id"]}} to attach the annotation to the investigated problem.SRE Agent — Root cause analysis.{{ result('call_sre_agent')['text'] }} to send SRE Agent action result as the annotation text.SRE Agent.{{event()["event.id"]}} to use the problem ID as an annotation ID. If you leave the field empty, a random id is generated.
If the same annotation id is used multiple times, the existing annotation is updated with the latest information instead of creating a new one.
You can configure the SRE Agent to automatically add details to the new ServiceNow or JIRA ticket after investigating a new problem, saving the time your team spends on the initial investigation.
In Dynatrace, go to
Workflows.
Select Workflow to create a new workflow.
Set the workflow trigger to Problem trigger. Configure the trigger as needed:
active.Availability and Error.dt.davis.is_duplicate == false to avoid overalerting.Select Add task > Run agent.
Configure the action:
SRE Agent from Ready-made agents.
Once you select an agent, you're able to review its functionality in Agent description.
Run a root cause analysis for problem with the id {{event()["display_id"]}}.Work outwards from the affected entities: their error and warning logs, the distributed traces of any service among them for the failing or slow span, the triggering metric's own time series where a threshold fired rather than the alert description alone, and how often this same alert name has already fired against the same entity in the last 24-48h.Judge what kind of problem this is and whether it needs attention. Synthetic, deliberately generated and test-origin alerts are noise and should be called out as such - a high, steady recurrence with no correlating logs is itself evidence of that. Where the evidence does not support a call either way, say so plainly and name what you checked, rather than offering a plausible guess.
Answer in this structure:**Verdict** - one short, self-contained statement the reader can act on: what kind of problem this is, what is happening, to which entity, and since when. One sentence.## Root Cause ReasoningName the root cause, then reason it through: the chain from that cause to the symptom the alert fired on, and why it happened when it did. Two to four sentences. Follow the system's causality, not your own train of thought.## RecommendationsThe remediating measures you recommend.## Evidence and findingsThe facts a reader needs to accept or challenge the verdict - for each, the entity it concerns, the value or timestamp behind it, and a link to its source. Whatever shaped the verdict belongs here: recurrence counts with the related problem ids, or a shared entity, cluster, namespace, naming, tag or alerting profile.## Additional instructions- Your response is parsed programmatically. It MUST start with the exact three characters `**V` (the opening of `**Verdict**`) as the very first characters of your output - no text, whitespace, reasoning, or planning statement may come before it. A response that starts with anything else fails this task outright.- Do not include any planning, confirmation, or narration sentence anywhere in the response - not before the verdict, not between sections. Examples of what this bans, verbatim: "I now have all the evidence needed", "Let me compile the findings", "The recurrence pattern is definitive", "Writing the report". If a sentence like this forms in your reasoning, discard it before responding - it must never reach the output.- Never comment on your own evidence. Drop phrases such as "I have all the data I need" or "the recurrence data is clear".- Never name your tools. No mention of the queries, files, commands or search results behind a finding.- Ground every finding in data you retrieved. Where you cannot point to that data, do not make the statement.- State every fact once, in the section the structure assigns to it.- Use at most 20 tool calls; the backend refuses more and a run that reaches the limit returns nothing at all, so stop investigating and write the report while calls remain - a short report with an open verdict beats running out.- Link source data with relative paths so it resolves on the current environment: an entity as [CheckDestination](/ui/entity/SERVICE-907DC3F55716BCC9), a problem as [P-2609087](/ui/apps/dynatrace.davis.problems/problem/P-2609087), logs as [Logs](/ui/apps/dynatrace.logs), Kubernetes as [Kubernetes](/ui/apps/dynatrace.kubernetes).- Where you reference an alert configuration, link where it is changed rather than the alert itself: [centralized alert management](/ui/apps/dynatrace.settings/settings/alerts).- Never invent an ID, and never write an absolute URL containing a host name. Only link an ID you actually retrieved.- Keep tables to three columns at most, and use lists, code blocks and iconography to make findings scannable.- Keep the report under 800 words.- Close with a finished report. Never offer to continue and never ask a question back; the report is read after the run has ended.Format the response for direct insertion into a ticket description field - no markdown tables, plain headers only.
You can enter a maximum of 10,000 characters in this field.
You can enter a maximum of 200,000 characters in this field.
Select Add task > Run JavaScript.
You need to provide a connector and credentials to run this action.
In the Input tab, enter the following:
import { executionsClient } from "@dynatrace-sdk/client-automation";export default async function ({ execution_id }) {const task = await executionsClient.getTaskExecution({ executionId: execution_id, id: "call_sre_agent" });const text = task.result?.text ?? "";await fetch("https://<your-instance>.service-now.com/api/now/table/incident/<sys_id>", {method: "PATCH",headers: { "Authorization": `Basic ${credentialVaultToken}`, "Content-Type": "application/json" },body: JSON.stringify({ work_notes: text }),});}
You can change https://<your-instance>.service-now.com/api/now/table/incident/<sys_id> to any other ticketing system you're using.
Optional Add any additional workflow action before or after the Dynatrace Intelligence agentic AI action to support your use case.
Select Save.
Select Run to execute the workflow.
You can configure the SRE Agent to notify the on-call team members about new problems by sending the message to the chosen app, such as Slack or Teams.
In Dynatrace, go to
Workflows.
Select Workflow to create a new workflow.
Set the workflow trigger to Problem trigger. Configure the trigger as needed:
active.Availability and Error.dt.davis.is_duplicate == false to avoid overalerting.Select Add task > Run agent.
Configure the action:
SRE Agent from Ready-made agents.
Once you select an agent, you're able to review its functionality in Agent description.
Run a root cause analysis for problem with the id {{event()["display_id"]}}.Work outwards from the affected entities: their error and warning logs, the distributed traces of any service among them for the failing or slow span, the triggering metric's own time series where a threshold fired rather than the alert description alone, and how often this same alert name has already fired against the same entity in the last 24-48h.Judge what kind of problem this is and whether it needs attention. Synthetic, deliberately generated and test-origin alerts are noise and should be called out as such - a high, steady recurrence with no correlating logs is itself evidence of that. Where the evidence does not support a call either way, say so plainly and name what you checked, rather than offering a plausible guess.
Answer in this structure:**Verdict** - one short, self-contained statement the reader can act on: what kind of problem this is, what is happening, to which entity, and since when. One sentence.## Root Cause ReasoningName the root cause, then reason it through: the chain from that cause to the symptom the alert fired on, and why it happened when it did. Two to four sentences. Follow the system's causality, not your own train of thought.## RecommendationsThe remediating measures you recommend.## Evidence and findingsThe facts a reader needs to accept or challenge the verdict - for each, the entity it concerns, the value or timestamp behind it, and a link to its source. Whatever shaped the verdict belongs here: recurrence counts with the related problem ids, or a shared entity, cluster, namespace, naming, tag or alerting profile.## Additional instructions- Your response is parsed programmatically. It MUST start with the exact three characters `**V` (the opening of `**Verdict**`) as the very first characters of your output - no text, whitespace, reasoning, or planning statement may come before it. A response that starts with anything else fails this task outright.- Do not include any planning, confirmation, or narration sentence anywhere in the response - not before the verdict, not between sections. Examples of what this bans, verbatim: "I now have all the evidence needed", "Let me compile the findings", "The recurrence pattern is definitive", "Writing the report". If a sentence like this forms in your reasoning, discard it before responding - it must never reach the output.- Never comment on your own evidence. Drop phrases such as "I have all the data I need" or "the recurrence data is clear".- Never name your tools. No mention of the queries, files, commands or search results behind a finding.- Ground every finding in data you retrieved. Where you cannot point to that data, do not make the statement.- State every fact once, in the section the structure assigns to it.- Use at most 20 tool calls; the backend refuses more and a run that reaches the limit returns nothing at all, so stop investigating and write the report while calls remain - a short report with an open verdict beats running out.- Link source data with relative paths so it resolves on the current environment: an entity as [CheckDestination](/ui/entity/SERVICE-907DC3F55716BCC9), a problem as [P-2609087](/ui/apps/dynatrace.davis.problems/problem/P-2609087), logs as [Logs](/ui/apps/dynatrace.logs), Kubernetes as [Kubernetes](/ui/apps/dynatrace.kubernetes).- Where you reference an alert configuration, link where it is changed rather than the alert itself: [centralized alert management](/ui/apps/dynatrace.settings/settings/alerts).- Never invent an ID, and never write an absolute URL containing a host name. Only link an ID you actually retrieved.- Keep tables to three columns at most, and use lists, code blocks and iconography to make findings scannable.- Keep the report under 800 words.- Close with a finished report. Never offer to continue and never ask a question back; the report is read after the run has ended.Keep the response under 200 words and lead with the Verdict - this is read in a chat channel, not a ticket.
You can enter a maximum of 10,000 characters in this field.
You can enter a maximum of 200,000 characters in this field.
Select Add task > Run JavaScript.
You need to provide a Slack webhook or Teams connector to run this action.
In the Input tab, enter the following:
import { executionsClient } from "@dynatrace-sdk/client-automation";export default async function ({ execution_id }) {const task = await executionsClient.getTaskExecution({ executionId: execution_id, id: "call_sre_agent" });const text = task.result?.text ?? "";await fetch(slackWebhookUrl, {method: "POST",headers: { "Content-Type": "application/json" },body: JSON.stringify({ text }),});}
Change slackWebhookUrl to your Slack webhook or Teams connector.
Optional Add any additional workflow action before or after the Dynatrace Intelligence agentic AI action to support your use case.
Select Save.
Select Run to execute the workflow.
You can configure the SRE Agent to use your investigation logic configuration for all problems detected during the last n days and prepare a digest, then save it to a [Showcase] Weekly Fleet Health Digest notebook.
In Dynatrace, go to
Workflows.
Select Workflow to create a new workflow.
Set the workflow trigger to Cron schedule trigger. Configure the trigger as needed:
0 8 * * 1 to run the investigation every 7 days.Select Add task > Run agent.
Configure the action:
SRE Agent from Ready-made agents.
Once you select an agent, you're able to review its functionality in Agent description.
Summarize the last 7 days of Davis problems across this environment using your available tools to list and investigate recent problems.Group findings by category (AVAILABILITY, ERROR, SLOWDOWN, RESOURCE_CONTENTION, CUSTOM_ALERT). For each category, name the most frequently recurring root-cause entities and judge whether the pattern looks like a real, worsening issue or recurring noise.
Answer in this structure:**Verdict** - one sentence: is the fleet healthier, worse, or unchanged versus a typical week.## HighlightsThe 3-5 most notable findings from the week, each with the affected entity and a one-line reason it matters.## By categoryA short paragraph per problem category present this week.## RecommendationsConcrete next steps, if any.This is a weekly digest, not a single-incident investigation - there is no triggering problem id, do not reference one.
You can enter a maximum of 10,000 characters in this field.
You can enter a maximum of 200,000 characters in this field.
Select Add task > Run JavaScript.
In the Input tab, enter the following:
import { documentsClient } from "@dynatrace-sdk/client-document";import { executionsClient } from "@dynatrace-sdk/client-automation";const DIGEST_DOC_ID = "614763ae-abfe-4a16-82c1-1a2a4108fc9d";export default async function ({ execution_id }) {const task = await executionsClient.getTaskExecution({ executionId: execution_id, id: "call_sre_agent" });const text = task.result?.text ?? "_Agent returned no output this run._";const doc = await documentsClient.getDocument({ id: DIGEST_DOC_ID });const content = await doc.content.get("json");const timestamp = new Date().toISOString();content.sections[0].markdown = `# [Showcase] Weekly Fleet Health Digest\n\n_Last updated: ${timestamp}_\n\n${text}`;await documentsClient.updateDocument({id: DIGEST_DOC_ID,optimisticLockingVersion: doc.metadata.version,body: { name: doc.metadata.name, content: new Blob([JSON.stringify(content)], { type: "application/json" }) },});}
Optional Add any additional workflow action before or after the Dynatrace Intelligence agentic AI action to support your use case.
Select Save.
Select Run to execute the workflow.
You can configure the SRE Agent to detect problems with high recurrence or problems open for a prolonged time and investigate the noise, then provide suggestions on reducing the number or recurring alerts in the problem annotation.
Workflows.active.Availability and Error.15 minutes or longer.dt.davis.is_duplicate == false to avoid overalerting.SRE Agent from Ready-made agents.
Once you select an agent, you're able to review its functionality in Agent description.
Run a root cause analysis for problem with the id {{event()["display_id"]}}.Work outwards from the affected entities: their error and warning logs, the distributed traces of any service among them for the failing or slow span, the triggering metric's own time series where a threshold fired rather than the alert description alone, and how often this same alert name has already fired against the same entity in the last 24-48h.Judge what kind of problem this is and whether it needs attention. Synthetic, deliberately generated and test-origin alerts are noise and should be called out as such - a high, steady recurrence with no correlating logs is itself evidence of that. Where the evidence does not support a call either way, say so plainly and name what you checked, rather than offering a plausible guess.
Answer in this structure:**Verdict** - one short, self-contained statement the reader can act on: what kind of problem this is, what is happening, to which entity, and since when. One sentence.## Root Cause ReasoningName the root cause, then reason it through: the chain from that cause to the symptom the alert fired on, and why it happened when it did. Two to four sentences. Follow the system's causality, not your own train of thought.## RecommendationsThe remediating measures you recommend.## Evidence and findingsThe facts a reader needs to accept or challenge the verdict - for each, the entity it concerns, the value or timestamp behind it, and a link to its source. Whatever shaped the verdict belongs here: recurrence counts with the related problem ids, or a shared entity, cluster, namespace, naming, tag or alerting profile.## Additional instructions- Your response is parsed programmatically. It MUST start with the exact three characters `**V` (the opening of `**Verdict**`) as the very first characters of your output - no text, whitespace, reasoning, or planning statement may come before it. A response that starts with anything else fails this task outright.- Do not include any planning, confirmation, or narration sentence anywhere in the response - not before the verdict, not between sections. Examples of what this bans, verbatim: "I now have all the evidence needed", "Let me compile the findings", "The recurrence pattern is definitive", "Writing the report". If a sentence like this forms in your reasoning, discard it before responding - it must never reach the output.- Never comment on your own evidence. Drop phrases such as "I have all the data I need" or "the recurrence data is clear".- Never name your tools. No mention of the queries, files, commands or search results behind a finding.- Ground every finding in data you retrieved. Where you cannot point to that data, do not make the statement.- State every fact once, in the section the structure assigns to it.- Use at most 20 tool calls; the backend refuses more and a run that reaches the limit returns nothing at all, so stop investigating and write the report while calls remain - a short report with an open verdict beats running out.- Link source data with relative paths so it resolves on the current environment: an entity as [CheckDestination](/ui/entity/SERVICE-907DC3F55716BCC9), a problem as [P-2609087](/ui/apps/dynatrace.davis.problems/problem/P-2609087), logs as [Logs](/ui/apps/dynatrace.logs), Kubernetes as [Kubernetes](/ui/apps/dynatrace.kubernetes).- Where you reference an alert configuration, link where it is changed rather than the alert itself: [centralized alert management](/ui/apps/dynatrace.settings/settings/alerts).- Never invent an ID, and never write an absolute URL containing a host name. Only link an ID you actually retrieved.- Keep tables to three columns at most, and use lists, code blocks and iconography to make findings scannable.- Keep the report under 800 words.- Close with a finished report. Never offer to continue and never ask a question back; the report is read after the run has ended.
You can enter a maximum of 10,000 characters in this field.
You can enter a maximum of 200,000 characters in this field.
{{event()["event.id"]}} to attach the annotation to the investigated problem.SRE Agent — Root cause analysis.{{ result('call_sre_agent')['text'] }} to send SRE Agent action result as the annotation text.SRE Agent.{{event()["event.id"]}} to use the problem ID as an annotation ID. If you leave the field empty, a random id is generated.
If the same annotation id is used multiple times, the existing annotation is updated with the latest information instead of creating a new one.