Order of operations in automation, alternative solutions

[Justus Hyytiäinen]

I have created a manually triggered automation that changes Start Date, End Date and Due Date of the trigger epic and other issues in the epic (with some conditions). After the automation has made the changes, I want to send the initiator of the automation a confirmation email with list of the issues updated. The list of issues is generated using Lookup action.

While testing this with an epic and only two issues in the epic, I ran into a problem with the email confirmation list. The list only includes the epic even though other issues have been updated as well. I've pinpointed the problem to automation order of operations: the Lookup issues action is carried out before the branched Issue field condition checks and Edit issue actions finish. Therefore, the Lookup list and the email message is missing the updated issues in the epic.

I've created a workaround using 20 something Re-fetch issue data actions before the Lookup issues action. This workaround fixes the problem at least in the scale I'm testing but I'm uncertain if this can cause some problems when scaled to epics with more issues in them. Are there some more robust and smarter ways of achieving this result available?

Please find picture of the automation rule below. For easier readability I've reduced the amount of Re-fetch issue data actions before Lookup issues to only two.

[Nic Brough -Adaptavist- · Accepted solution]

The service desk portals live under the base url given for your Jira system.

You could put a proxy in front of them with a different cname, but it will come back to using the base url quite quickly.

[Menouer Nobach]

Hi Nic,

I know the portal link lives under the base url, but the problem with that is that you still have the ":port/portal/customer/number" which looks kinda ugly so that wouldn't be a solution to my question unfortunately.

Regards,

Menouer 

[Daniel Eads]

Hi Menouer,

Jira internally will not change the URLs for any hyperlinks it generates once you land in Service Desk. So Nic is correct; you can create something like "help.domain.com" using a reverse proxy, but once you actually arrive there, any links the user clicks will go someplace like "jira.domain.com/portal/customer/94".

I'm sorry if that's not the answer you're looking for! Unfortunately it's how the system works right now. There is an open feature request to allow custom URLs: JSDSERVER-1627 - I recommend watching and voting on that feature request. For more information about how Atlassian prioritizes feature requests made on jira.atlassian.com, check out this Community post.

Cheers,
Daniel

[Simon Evans]

Hi Daniel,

JSDSERVER-1627 is not capturing the issue here.

JSDSERVER-513 is the correct ticket, and should be done, like zendesk and others. (it has the highest votes of any open issue)

This is a cumbersome workaround for something simple that shoud be in service desk.