Automation: select issue(s) inside the automation rule

[Richard Vencu]

I want to integrate Jira with another system that is unaware of Jira issue keys. They can only send their own ticket ids and I plan to store these ids into a custom field in Jira for reference.

Now, I can access a scheduled REST API to refresh information from the remote system. All I get into the webhook data is a list of issues with their ids and other info. I seek a way to update info for all existing Jira issues based on custom field values and also create any new issues for the items that appear new in the remote system interrogation.

Except coding my own third party sync app against the remote system and Jira and do the entire logic there, is there any chance I can simply use Jira automation to perform this task?

So far I stumbled upon these problems:

- did not find a way to iterate the webhook data (loops)

- did not find a way to declare issues I want to work on except if they are defined in the first step

About the last problem, I noticed if I am using an incoming webhook and do not pass any issue key within it I am only limited to creating new issues. I see I can query issues now with JQL and put them in {{lookupIssues}} smart value but then, no way to update an issue that I know its key on subsequent actions.

[nmenere · Accepted solution]

Hi Richard,

You can "Branch" on JQL and you could iterate on that list of issues but you aren't going to be able to use the webhook data to then edit those issues.

And you wouldn't be able to identify when there is no corresponding issue.

We have a feature request open to iterate over arbitrary objects which would enable this but unfortunately, until we implement that we can't support this sue-case.

Cheers,
Nick [Automation Group Product Manager]

[Richard Vencu]

Thanks, I am interested to see the new functions once they arrive.

I was able to build an automation rule that uses lookupIssues with this trick: in case there is another issue already created related to the foreign key, I make a clone of the triggering issue then delete it.

The clone just changes issue type to subtask and is attached as a child of the found issue by using the custom smart value (see diagram)

Later a second rule takes the description of the subtask and adds it as a comment in the parent, then deletes the subtask.

Finally I was able to add new incoming emails as comments to issues by searching for the foreign key.

It is a bit over complicated but it works. I am sure your new features would simplify the approach.