How to update the work type of an item dyanmically using a Rovo agent in an automation rule

[Charlie Misonne]

Hi Community!

For context: I have a Rovo agent that reads a table on a Confluence page. The first column of the table contains some key words. The second column the name of a work type.
The Rovo agent checks if the keywords are present in a work item's summary and return the work type from the second column.

With an automation rule I want to edit the work type based on what the agent found. So I have a Rovo action to invoke the agent and in the next step I edit the work type with {{agentResponse}}.

I already made sure the agent outputs just the value and nothing else.

The automation rule fails with:

(The issue type selected is invalid. (issuetype))

Apparently the automation rules expects the ID of the work type and not the name. When manually using the ID it works.

But how can Rovo return IDs for work items? When I ask "Can you provide the IDs for each work type?" it sometimes tells me it can not get the IDs or it returns the wrong ones.

Of course I could add the IDs to my table as a workaround but I prefer the names.

[Bill Sheboy · Accepted solution]

Hi @Charlie Misonne 

First thing, a "watch out" disclaimer:

Changing a work item's type can be problematic in automation rules due to site configuration, workflow, space configuration (the "project" one, not the Confluence one ;^) and other differences.  This is one reason Atlassian provides the specific "move" UX function to guide a person through the steps, asking clarifying questions to help.  A rule cannot pause to ask such questions.  When one wants to change types in a rule, I strongly suggest fully investigating edge cases to handle them in the rule, and anticipating the rule will regularly fail, with or without errors in the log.

Back to your question, the destination work item type ID value is required, even when using the bulk-move endpoint directly in a rule.  Your rule could first call the endpoint to get all types for the destination project, using the Send Web Request action, and use those to map the type names to their ID values.  That could be done with a dynamic regular expression with match() or by creating a dynamic lookup table from the web response to get the types.

https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-types/#api-rest-api-3-issuetype-project-get

Kind regards,
Bill

[Charlie Misonne]

Hi Bill,

I am well aware of the what a change in work type can mean. Thanks for pointing it out though!
In my project each work type has the same workflow, screens, etc. so I'm able to easily edit the work type.

Good idea to fetch the IDs via a REST call.

I was hoping to get a Rovo solution but I guess Rovo is not reliable to fetch that kind of information.
For now I just included the IDs as a separate column in my table and I can ask Rovo to return the text values or the IDs. It works fine.

When the table gets longer I might add the extra api call step.

kind regards

Charlie

[Dr Valeri Colon _Connect Centric_]

@Charlie Misonne  You’ve essentially reached the current boundary of what Rovo inside Automation does well. Rovo is reliable at reasoning and returning clean text values, but it isn’t reliable at discovering or resolving Jira system IDs on the fly. Jira Automation requires the issue type ID, not the display name, and Rovo doesn’t have a dedicated skill to consistently fetch or validate those IDs during an automation run, which is why it sometimes guesses or fails.

The most stable approaches today are either including the issue type IDs directly in your Confluence lookup table and having Rovo return the ID, or using an Automation web request to call the Jira REST API to retrieve the project’s issue types and map the name to the correct ID in the rule. In practice, Rovo is best used to decide which work type applies, while Automation or the REST API should handle translating that decision into the correct system ID.

[Charlie Misonne]

Hi @Dr Valeri Colon _Connect Centric_ 

Thanks for elaborating on this subject.

It confirmed what I suspected: Rovo is not suited (yet?) on its own for this.

It would be great if the technicalities of Jira like custom field IDs, work type IDs, etc. would be added by default in Rovo's knowledge.

Currenlty my solution works really well. I added the IDs in the table manually. I don't want to perform an API call just for this in the automation rule.  I would if my data source was larger but currenlty it only needs to know about 5 work item IDs.

[Dr Valeri Colon _Connect Centric_]

Your workaround makes perfect sense given the scope. When it’s just a few IDs, adding them manually is way more efficient than setting up a full API call. That kind of practical thinking is what makes real-world use cases so valuable.

And yes — Rovo having more awareness of Jira’s technical elements like custom field and work item IDs by default would be a huge step forward. You’re definitely not alone in hoping for that.

Thanks again for sharing your solution so clearly. It’s exactly the kind of insight others can learn from, and it helps push the conversation in the right direction. I’ll tag you if I see anything shift in that area.