Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,363,018
Community Members
 
Community Events
168
Community Groups

Migrating Legacy Automation rule which triggered when linked issue changed status

We have a service desk project, and several software projects. Let's call them SDP, SOFT1, SOFT2, SOFT3. We have a Legacy Automation rule which triggered on "A linked issue is transitioned". In addition, we have a field in our SDP issues called "Follow Up", which is a date. This is used to allow our users set a date that they want to follow up on on a issue. We have reports which show our users all of their issues that have "Follow Up" dates <= today.

Our workflow is currently that when service desk issues are opened, we then create engineering issues in SOFT1, SOFT2, and SOFT3, depending on the project it's related to. Our Legacy Automation rule is set up to run an "Action" transition on the SDP issue when any of the issues linked to the SDP has any transition, i.e. work begins, work completes, etc. This "action" transition sets the "Follow Up" field in the SDP ticket, so that the assignee knows that they should take a look at the issue again, and see if there is anything to report to the client.

The benefit of this legacy automation rule is that we define it once, for the SSD project, and issues linked from any other project SOFT1, SOFT2, SOFT3, etc, will trigger the rule.

We would like to depreciate the legacy rule and the "action" in the workflow, and replace it with one new "Automation" rule. I can't for the life of me figure out a way to create an non-Legacy Automation Rule for SDP project that gets triggered when a ticket linked to SDP project changes status. It that possible, or do we need to stick with the Legacy rule and the "action" transition.

To give a little more insight, the reason we went with the legacy rule then using the "action" transition was because the legacy rules could only set a date field to a fixed date. i.e. there is no support for setting a date field to "today()"

Basically we're looking to implement a rule like this:
If any linked issue to SSD project changes status, set the "Follow Up" field to "today()"

If anyone has other thoughts on how to do this, that would be appreciated as well.

1 answer

0 votes
Jack Brickey Community Leader Sep 10, 2022

Hi @Benjamin Peikes ,

first let me thank you for the very well documented process and problem statement here. It isn't often that we get this level of detail so kudos for that.

I believe that this should be possible and I may take some time today to play with it and see if I can get something working. But here's my thinking, I realize that you may have already thought through this process so I may be just repeating what you already have attempted unsuccessful.

You should have a rule in your software projects that trigger on transition. There should be a condition in this rule to check and see if there is a link to your SDP project and if so take the appropriate action on that linked issue. Then you should have a rule in your SDP project that triggers based on the action taken by the other rule.

anyway that's it at a high-level. Can you comment on your attempt to do something similar? Again I will see if I can take 30 minutes to an hour to play with this and get something real working.

Thanks, but the problem with that solution is that you need to do that for all projects that have issues linked. i.e.

Lets say for project A, you want any issue updated with a new value for "Follow Up" any time the status of a linked issue changes. project A might have linked issues from several projects and issue types, all which have their own workflows. We don't want to have to add automation rules for all of those projects.

I suppose we could make it a global automation rule, but only make the update if the linked issue is in project A. The issue with this, is that it means the rule triggers for every issue transition, but maybe that's necessary.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Site Admin
TAGS

Atlassian Community Events