Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Complicated Automation for Transitioning Issues

GC
Contributor
July 5, 2024

Hi guys, 

I've been racking my brain trying to figure out how to set up a wide variety of automation rules to keep epics and their children in line. 

I have the following scenario which I'd like to cover but I am not sure how to set the automation up:

  • Whenever a new ticket is added/removed from an existing epic, I'd like an automation to check if the status of the epic needs to be changed based on the status of the child. The complexity here is that:
    • I want this to apply to all the projects we have in our Jira instance and all of them have different workflows with different statuses making selecting specific statuses for the automation rule difficult nigh impossible 
    • Even within a single project, epics and their children also have different workflows and statuses available, making it even more difficult to match up. eg, children may have a 'in progress' status whilst the equivalent in their epic workflow is 'in development' 

Example of what I want to be able to do:

  • When a new ticket is added to an epic and this ticket is in progress, if the epic was already closed (done) or not yet started (backlog), I want it to transition to its equivalent 'in progress' status whatever that may be.
  • When a ticket is removed from an epic, if this child was the only one 'in progress' for example, and all others are 'done' then the status of the epic should change to 'done' 

I already have in place automations to change epic status according to changes in its children but thats for existing children, I'm struggling to make this work for when the trigger is the addition or removal of a ticket.

Initial questions:

  • Will I have to create 1 rule per status or can I just do branches within the same rule for the automation to apply the transition relevant to the status of the child? I can't seem to find the if/else block which is part of my confusion in trying to just 'branch' this within one rule - has Atlassian gotten rid of this? 
  • For any of this to work, will I essentially have to align all statuses so that the automation can work? or can I somehow use StatusCategory and transition based on this? 

Thanks and apologies for the longwinded and hopefully not too confusing question! 

3 answers

1 vote
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 5, 2024

Hi @GC 

This is a challenging scenario to solve for non-trivial Jira site configurations.  Perhaps start small, with a single project and then scaling up to handle other projects / types.

You appear to be using a Jira Premium license level, and so I hypothesize you have many projects, of different types (including Company-managed, Team-managed, JPD, Work Management, etc.), and multiple different workflows for different issue types and projects.

If that is the case, I suspect what you describe cannot be done with one rule.  At a minimum it may require:

  • For each project type (plus one for each team-managed and JPD project) and for each workflow
    • A rule triggered on issue transitioned, handling the specific conditions
    • A rule triggered on changes to the parent field, to handle add / remove / change of epic parents.  For the remove and change cases, the previous parent will also need updates.
    • A rule triggered on issue deletion...
    • A rule triggered on issue creation...

In some cases, those rules may need to enable the option to allow other rules to trigger them (if other rules perform issue transitions, creation, and edits).

Trying to merge the different paths / conditions in fewer rules will increase risk, complexity, and the chances of errors which are difficult to undo.

 

And...just because rules could handle some scenarios / edge cases, perhaps it would be better to not handle all of them.  Applying the 80 / 20 rule could reduce the complexity of the rules and leave more challenging ones to manual intervention.

 

Kind regards,
Bill

0 votes
GC
Contributor
July 8, 2024

@Jovin @Bill Sheboy Thank you both for your answers.

I have inherited a system where all of these different workflows already existed so dealing with that has been a challenge.

I think I'm going to try and align as many workflows as possible first then try some of the solutions you've mentioned. 

0 votes
Jovin
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 5, 2024

Hey @GC ,

Sounds like you're trying to create the one rule to rule them all! Let's break it down a bit...

Firstly - aligning all statuses across your instance would definitely simplify and help; as would workflows, but we can work around this to a certain extent.

Triggers

  • Existing issues are easy - "issue transitioned" works well here and you can simply leave the FROM and TO sections of this trigger empty to match all
    • After this if you ONLY want your child issues to trigger this (e.g. don't want the Epics driving the children) put a condition in of "Issue fields condition" based on the issue type.
  • Adding/removing links - "Field value changed" is the trigger you want and you want to look for Parent, you can do all value changes here if you want

Conditions

  • To prevent errors, I'd recommend having a IF statement where you're checking that the parent is not empty so use "Related issues" condition and choose parent, THEN go for the branches

Branches

  • You'll repeat this multiple times for EVERY destination epic status - the branch is related issues and choose Parent
  • Then add a condition of Issue fields condition
    • Field: Status
    • Condition: Is one of
    • Values: choose all of your values relate to your parent EPIC's destination status
  • Then in the branch add an action to transition issue to your desired status

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events