Rovo Agent automation related query

[Testing]

I have created rovo agent for perform the weekly analysis and generate report of identifying top 5 problem request we received on weekly basis in which escalation required, below prompt i used:

------------------------------------------------------------------------------------------------------------------------------------------------------------

"Analyzes support tickets from the last 15 days, identifies the Top 5 problem types, assesses Engineering escalation need, and generates an executive summary.
You are a Support Operations Analyst. Your job is to analyze recently created support tickets and produce a clear weekly trend report for Support and Engineering leadership.
Scope
Analyze only tickets created in the last 15 days.
Use these fields only: Summary, Status, Issue Type, Priority, Labels, Components, Created Date, Resolution.
Do NOT use the Description field unless absolutely necessary (to minimize context usage).
Analysis Requirements
Group similar tickets into meaningful problem types/trends based primarily on the Summary field.
Identify the Top 5 problem types by ticket volume.
For each of the Top 5 problem types provide:
Problem type name
Total number of tickets
Number of currently Open tickets
List of relevant Jira ticket keys
2–3 representative ticket summaries
Priority breakdown (if meaningful)
Engineering Escalation Assessment (for each of the Top 5):
Recommend Yes / No / Monitor
Base the recommendation on: frequency, recurrence of the same technical problem, customer/business impact, production impact, and blocker/critical symptoms mentioned in the summary.
Do NOT rely solely on the Jira Priority field - priority data can be inaccurate. Explicitly highlight any potentially under-triaged blockers or high-impact issues.
Output Format (strictly follow this structure)
Weekly Support Trend Analysis
Reporting Period: [Start Date] – [End Date]
Generated on: [Today's date]
Top 5 Problem Types (Summary Table)
Number
Problem Type
Tickets
Open
Escalate to Engineering?
1
[Problem Type Name]
X
Y
Yes / No / Monitor
2
[Problem Type Name]
X
Y
Yes / No / Monitor
3
[Problem Type Name]
X
Y
Yes / No / Monitor
4
[Problem Type Name]
X
Y
Yes / No / Monitor
5
[Problem Type Name]
X
Y
Yes / No / Monitor
Detailed Breakdown
1. [Problem Type Name]
Total Tickets: X
Open Tickets: Y
Ticket Keys: KEY-123, KEY-124, KEY-125...
Representative Summaries:
"..."
"..."
"..."
Priority Breakdown: High: A | Medium: B | Low: C
Engineering Escalation: Yes / No / Monitor
Rationale: [brief explanation]
(Repeat the same detailed structure for problem types 2–5)
Key Observations & Trends
Bullet points of important patterns
Recommendations for Engineering
Numbered list of actionable recommendations
Potentially Under-Triaged High-Impact Issues
List any tickets that appear to be blockers or high-impact but have lower priority
Source Data
JQL used: project = "YOUR-PROJECT-KEY" AND created >= -15d ORDER BY created DESC

------------------------------------------------------------------------------------------------------------------------------------------------------------
And then i created automation that publish confluence page based upon agent analysis, now I want automation can also edit top 5 issues field problem type identify by Rovo Agent as problem.

let me know how to fix automation I created ROVO Agent "Weekly Support Trend Analyst" and automation in project which successfully generating Confluence page and I want one additional activity i.e edit work item custom field Problem Type as well based upon rovo agent analysis.

[Jovânio Junior]

Hi - glad to see you already have the hardest part working: the Rovo analysis is being generated and your automation is successfully publishing the Confluence report.

For the additional requirement, I would **not ask the Rovo agent itself to edit the Jira work items** inside the automation. When a Rovo agent is invoked from Automation, Atlassian documents that it can only return a response; its own tools are not executed. The actual update should be done by a subsequent Jira Automation action using the agent output. ([Atlassian Support][1])

The cleanest design would be:

**Scheduled rule → Use Rovo agent → Agent returns structured JSON → Branch through returned issues → Edit “Problem Type” field**

The key change is your agent output. Right now the response is optimized for a human-readable Confluence report. I would additionally ask the agent to return a structured list containing the issue key and the identified Problem Type.

For example:

```json
[
{
"issueKey": "SUP-123",
"problemType": "Authentication failures"
},
{
"issueKey": "SUP-145",
"problemType": "Authentication failures"
},
{
"issueKey": "SUP-167",
"problemType": "API timeout"
}
]
```

In the agent prompt, add something like:

```text
In addition to the report, return a machine-readable JSON list containing every Jira issue included in the Top 5 problem types.

Return only valid raw JSON for this section, with this structure:

[
{
"issueKey": "KEY-123",
"problemType": "Problem Type Name"
}
]

Do not wrap the JSON in markdown code fences.
```

This is important because Atlassian Automation can parse a Rovo response as JSON using `{{agentResponse.asObject}}` or `{{agentResponse.asList}}`. Atlassian specifically documents `.asList` as useful when you need to iterate over values returned by an agent. ([Atlassian Support][2])

Then, after **Use Rovo agent**, add a branch over the returned list and use **Edit work item** inside the branch.

Conceptually:

```text
Scheduled trigger
↓
Use Rovo agent
↓
Create/update Confluence report
↓
Branch over {{agentResponse.asList}}
↓
Edit Jira work item
Problem Type = value returned by Rovo
```

The exact smart values would depend on the final JSON structure. For example, if the response is a list like the example above, you would want the branch to expose something equivalent to:

```text
issueKey
problemType
```

and then edit the matching Jira issue using the returned key.

There is one important catch with your current design: **you are using the same agent response both as a formatted executive report and as machine-readable data.** That can become difficult to parse reliably.

I would therefore recommend one of these two designs:

**Option A — best for reliability**

Use **two Rovo actions**:

1. First Rovo action → generate the formatted Confluence report.
2. Second Rovo action → return only JSON containing issue keys + Problem Type.
3. Branch over that JSON.
4. Update the Jira custom field.

**Option B — single Rovo call**

Change the entire agent response to structured JSON and then build the Confluence page from those values as well.

For your existing automation, **Option A is much easier** because you do not need to break the report that is already working.

Also, Atlassian has a recent KB specifically covering this scenario: when a Rovo agent returns JSON, using something such as:

```text
{{agentResponse."Problem Type"}}
```

will not work because the default response is treated as a string.

Instead, you need to parse the response, for example:

```text
{{agentResponse.asObject."Problem Type"}}
```

Atlassian also recommends returning **raw JSON without ```json code blocks**. ([Atlassian Support][3])

So my recommended implementation for you would be:

```text
1. Scheduled trigger
2. Use Rovo agent - Weekly Support Trend Analyst
3. Publish {{agentResponse}} to Confluence
4. Use Rovo agent again
Prompt: return only issueKey + problemType as JSON
5. Branch over the JSON list
6. Edit each returned Jira work item
7. Set custom field "Problem Type" = returned problemType
```

One additional consideration: decide whether **Problem Type** should be a free-text field or a controlled **single-select field**.

If Rovo can invent category names every week, you could end up with values such as:

`Login issue`
`Login problems`
`Authentication issue`
`Authentication failures`

which are essentially the same category.

For reporting, I would prefer a predefined select list and instruct Rovo to choose **only from an approved set of Problem Type values**. That will give you much cleaner trend reporting over time.

Your concept is absolutely feasible — I would just separate **Rovo classification** from **Jira field editing**, letting Automation perform the actual update.

If you share a screenshot of your current automation rule, I can help you map the exact next actions and smart values without rebuilding the part that is already working.

[Testing]

you mean i need to modify the agent and ask for json based respond as well over confluence page? If yes then can you guide what exactly i can add in automation to modify the work item.