nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Rovo on the portal creates cards only with summary

David Foote_h3fjnl

Hi all,

We have been exploring adding a Rovo agent on the portal to replace the virtual service agent we have currently.

Generally, we like the responses from Rovo better, but it seems to do a terrible job when actually creating a request. It always seems to create cards with only a summary, despite many attempts at getting it to fill in the description as well.

Has any one had success with the create request skill? Even just copying the chat or initial question into the description would be better than the nothing we get currently!

Accepted answers

Dr Valeri Colon (Connect Centric)

Hi @David Foote Rovo’s Create Request skill on the JSM portal is still limited. It often copies only the summary because the portal flow doesn’t reliably pass the full conversation text into the Description field. This isn’t a configuration issue on your side—it's a current product limitation. The best workaround is to add very explicit agent instructions like “always populate the Description with the full customer message,” but even then results vary. Atlassian is improving field mapping, but there’s no reliable fix yet.

All comments

Jorge Cammarota_rnitw6

Some Important Points and What Can Be Done Today:

Current Rovo Behavior (Product Limitation)

Rovo is still "learning" to better map conversation text to Jira Service Management form fields.

Currently, it tends to:

Always fill in the Summary.

Fill in the Description only in some types of forms or when the internal flow/mapping can clearly identify the "problem detail."

There is, to date, no native configuration like "always copy chat content to the ticket description."

Why Sometimes Only the Summary is Populated

In practical terms, this usually happens when:

The request form has many structured fields (select, checkboxes, etc.) and little emphasis on the "Description" field, so the model prioritizes filling what is mandatory/structured.

The agent's internal prompt is more focused on classifying the request and summarizing, rather than "transcribing" the conversation.

There is little explicit instruction in the agent or on the form stating that the description should contain the full request text.

Workarounds That Usually Help Today

You can't force it 100%, but you can significantly improve the success rate by combining some practices:

a) Instruct the User in the Portal

In the queue/form introduction text (Description of the request type), you can guide the user to write something like right from the start:

"Describe your problem in detail in your first message. This text will be used as the ticket description."

This helps the model identify "this is the description" and, in some cases, it indeed copies this content.

b) Instructions in the Rovo Agent

In the Rovo agent editor, adjust the system/behavior instructions (if available in your tenant) to something like:

"When creating a request in Jira, use the full text of the user's initial question as the ticket description. If necessary, also copy relevant information from the conversation."

This is not guaranteed (due to current product limits) but improves model alignment.

c) Use Custom Fields Instead of Relying Only on Description

If there is critical information you need copied, consider:

Creating mandatory custom fields (e.g., "Problem Detail," "Impact," "How to Reproduce").

In the agent's instructions, emphasize: "Always fill fields X, Y, Z with the information provided by the user."

In practice, the model tends to handle clearly named and expected fields better than a generic text field.

d) Automate a "Fallback"

You can create an automation in Jira Service Management that:

Trigger: When a ticket is created via the portal/Rovo,

Condition: If Description is empty,

Action: Copy the value from the Summary (or another field) into the Description.

It's not perfect (it becomes redundant), but it ensures you never have a completely blank description.

Regarding "Copying the Chat or Initial Question to the Description"

There is currently no native option like: "always include the conversation transcript as the description."

What sometimes works better is:

The agent producing a detailed summary (in continuous text) of the conversation,

And, through prompt instruction, using that summary as the Description.

Depending on how your agent is configured (and the capabilities enabled on your site), it's worth reviewing the prompt and making this very explicit.

What I Would Recommend Doing Now

In practical terms, for your scenario:

Set up an Automation Rule:

Trigger: "Issue created" in the service project used by the portal.

Condition: "Description is empty."

Action: "Edit issue" → Description = {{issue.summary}} or, if you want something richer, concatenate other fields.

This solves the "zero information" issue today.

Review the Request Form:

Confirm that the "Description" field is:

Visible in the portal,

Well-described ("Here you should detail the problem; the content will be used by the agent to log the ticket").

Avoid an excess of mandatory fields that confuse the intent.

Adjust the Rovo Agent Prompt:

Add something like:

"Whenever you create a ticket, populate the description with:

The user's initial question, and

The relevant details collected during the conversation."

Product Status / Expectation

According to reports from other admins, this is a known limitation that is still evolving.

A tendência é que, em versões futuras, o Rovo:

Preencha melhor a descrição,

E ofereça controles mais explícitos sobre o mapeamento de conversa → campo do ticket.

Rebekka Heilmann (viadee)

Hi @David Foote

how are your Request Types structured. Are you using Forms within the Request? To my knowledge, Rovo still cannot access Form Fields so it would only fill in any Jira field shown in the Request.

David Foote_h3fjnl

Yes - forms are so powerful for human input almost all of our request types are associated with one.

Dr Valeri Colon (Connect Centric)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

portal

rovo-atlassian-intelligence