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 Agent Unable to Jira Read Form Data

Becky Koke

Hi,

I have been using forms heavily in Jira Service Management for several of years now, and was looking forward to creating Rovo Agents to automate some processes for my team -- like updating the issue due date based on volume of work, or automatically creating a Confluence page for the issue.

Sadly, I've come to find out that Rovo is completely BLIND when it comes to Jira forms. I am really shocked and disappointed to find out about this! It can read Teams messages but not data that lives right here in Jira? It also can read attachments to the tickets beautifully, but not our forms in Jira. Apparently my only option is map certain form data to custom fields which is not ideal - especially when it comes to creating Confluence content based on information entered into the form.

This feels like a huge gap in all the big promises we've been hearing about Rovo and all it can do. Does Atlassian have plans to update Rovo so that it can see all of my Jira data?

Accepted answers

Ajay _view26_

Hi @Becky Koke

This is a real gap , Rovo agents currently can't read data stored in JSM forms natively. Forms in Jira Service Management are a separate data layer from issue fields, and Rovo's access to Jira issues goes through the standard issue schema (fields, comments, attachments), not the form submission payload.

All comments

Ajay _view26_

Hi @Becky Koke

Olha Yevdokymova_SaaSJet

Hi @Becky Koke

Here I’d separate two things: what needs to become Jira fields, and what only needs to stay as structured context.

If every Level 2 / Level 3 / Level 4 / Level 5 value does not need to be used separately for reporting, workflow conditions, assignment, or automation, I would not map every form field to a separate Jira custom field. That can make the Jira work item layout very heavy and harder to maintain.

A cleaner approach is to map only the key fields that Jira actually needs — for example, the final classification, priority, team, or request type — and bundle the rest of the form responses into the issue Description.

In Smart Forms for Jira, developed by my team, you can map multiple form values into one Jira field, such as the Description field. For example, the created issue could include something like:

Level 2: Infrastructure
Level 3: Database
Level 4: DBA Support
Level 5: Backup Configuration

This keeps the request readable for the assignee, without creating unnecessary Jira fields for every hierarchy level. The detailed response still stays stored in the Smart Form itself, so the team can open the form on the issue and review the full structured submission when needed.

You can also create Confluence Page from form responses using rovo and automation, cause everything in description is already formatted like Element label: Response
here is an example but without rovo and bundled fields

Another useful option is Rovo Agent developed specifically for Smart Forms. Since the responses are stored in forms, Rovo can help analyze submitted form data, summarize responses, identify patterns, and make it easier to understand what users are selecting across multiple submissions. That can be helpful if you want insights from the hierarchy data without turning every single answer into a Jira field.

Daniel Cotter

Agree, this is a huge limiting factor, Rovo needs to be able to use the context generated by the forms.