The Rovo induced automation dilemma

[Don Hames]

I encountered an interesting situation while creating a Rovo Agent with an automation Trigger. Automation rules are usually triggered by an action that grants access to the issue(s) the rule is designed to process. Meaning that by the time the automation rule is triggered and running, it already knows about the current issue or issues if JQL is used.

If the automation rule is triggered by a date (which allows you to run a JQL query to load the issues if you had it ahead of time) or by some other action that is triggered by an issue, you would have the issue(s) loaded. You can use everyday automation actions to perform updates and other tasks on the issues.

In this case, the automation rule is triggered, which then invokes a Rovo Agent. The agent generates a JSON file containing issue keys and other values that need to be updated in the issues.

Here's the dilemma: The automation rule is triggered without knowing what issue(s) are involved, so it cannot load the issues in preparation for the automation actions.

I can loop through the JSON file (using the For Each: Smart Value component) and now have one set from the JSON file with the issue key and fields to update.

However, I don't see any action that allows the issue key to load the issue, so that the regular automation actions can update it.

I hope this is not the result of too little caffeine or sleep, or both, but how can you get there from here?

Thanks in advance for your shared wisdom. It is and always will be appreciated.

[Bill Sheboy · Accepted solution]

Hi @Don Hames 

Without seeing your entire rule for context...

You could parse the keys out of the JSON, using that to create a dynamic JQL expression, and then branch to the issues for edits.

And, if the JSON is only recognized as text, you could use the jsonStringToObject() function first to more easily parse the data to create the JQL.

Kind regards,
Bill

[Don Hames]

Hi @Bill Sheboy 

Thanks for the quick response! Your suggestion sounds like it would work great. Can you explain a little about what you mean by a dynamic JQL expression? Thanks!

[Bill Sheboy]

No problem, @Don Hames 

Let's assume the smart value could be parsed into JSON, and it had a list with an attribute named "key" with the work item's key.  The dynamic JQL might be this:

key IN ( {{jsonStringToObject(mySmartValue).key.distinct.join(", ")}} )

That might produce a result like this:

key IN ( ABC-123, ABC-456, ABC-789 )

And that JQL could be used in the branch.

[Alex Gallien · Accepted solution]

Totally see the dilemma here @Don Hames!

The only way I can think of to get around this would be to loop through your JSON as you're doing, then use the Send Web Request action to hit PUT /rest/api/3/issue/{issueIdOrKey} to make updates to your work items.

If you haven't worked with that action before, see How to extend Automation for Jira with REST API calls. That article is for Data Center, but the same process applies. One important difference to be aware of is that you can now hide the value of your authorization header in the rule to avoid leaking your API key.

[Don Hames]

@Alex Gallien 

I appreciate your reply and the great suggestion! I have not used a Web Request in the way you are suggesting, but I have read the article and plan to give it a try this morning. 

I can see that if this solves my current issue, it could be used for several other purposes. I will get back to you as soon as I test it to let you know how it worked for me. Thanks again, Alex.