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; } } }

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.

Accepted answers

Bill Sheboy

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

All comments

Bill Sheboy

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.

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.

Welcome!

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

Quick Links

Find more posts tagged with

jira-automation

rovo-atlassian-intelligence