How to automatically link issues based on field in related epic

[Dillon Kenniston]

Hi there,

My goal is to automatically create sub-tasks to our release ticket (so assignees can approve the set of tickets in the release for which they're the beneficiaries), and then link tickets for which assignees are "Product Beneficiaries" to those sub-tasks.

For example, if the "Product Beneficiary" is John Smith for tickets A, B, and C in release 1.23, then a sub-task should be created and assigned to John Smith to approve tickets in the release, and then tickets A, B and C should be linked to that sub-task so John Smith knows which tickets to approve.

I already have 2 rules:

Rule 1 creates sub-tasks, one for each Product Beneficiary. This is being done successfully.

Rule 2 assigns the sub-tasks, one for each Product Beneficiary. This is being done successfully.

What remains is to automatically link the tickets in view to these newly-created sub-tasks. I'd like to create Rule 3 for this.

The linking logic should go as follows:

1. Lookup all issues tied to the release
2. Group the issues in the release by "Product Beneficiary" (user: John Smith). The "Product Beneficiary" is set in the Epic of the issues in the release. (Assume all issues in the release have epic assignments.)
3. Link that subset of issues in the release to the sub-task where the issue belongs to an epic on which John Smith is the assigned "Product Beneficiary".

Example:

• Epic "Write Code" has Product Beneficiary John Smith. Of issues in release 1.23, 10 belong to the "Write Code" epic.
• Epic "Deploy App" has Product Beneficiary Jane Doe. Of issues in release 1.23, 13 belong to the "Deploy App" epic.
• Rules 1 and 2 work together to create 2 sub-tasks on the ticket for Release 1.23: one sub-task assigned to John Smith, another assigned to Jane Doe.

Desired Outputs:

Automatically link tickets in release 1.23 from "Write Code" epic (where John Smith is Product Beneficiary) to John Smith's sub-task.

Automatically link tickets in release 1.23 from "Deploy App" epic (where Jane Doe is Product Beneficiary) to Jane Doe's sub-task.

Any help would be appreciated. Thank you!!!

[Bill Sheboy]

Hi @Dillon Kenniston 

This is complex use case, tailored your your team's usage of Jira, although it may not have seemed that way when it was implemented by manually changing the issues. 

I recommend having a discussion with your Jira Admin on how to implement this with rules, and how to handle any exception/edge cases possible.

Rules appear not to have been designed to nest branches and this scenario needs that capability.  So a work-around may require chaining of rules to trigger them in coordinated succession.  Because of this complexity I recommend asking your admin for help, and they may help find a solution.

Kind regards,
Bill

[Dillon Kenniston]

Hey @Bill Sheboy - thanks for the response. I'm a Jira Admin and this one's got me stumped :)

In my mind, the hard part isn't so much running rules in a particular order, or related to anything unique to our Jira instance. I would have thought (seems wrongly) that this is a common use case: business stakeholders (in Epics) review some subset of tickets in a release, with the goal of automatically linking related tickets so business stakeholders know which tickets are theirs to review.

In Jira's Automation Template Library, there's a rule that seems close to what I'm trying to accomplish, below.

I'm not familiar with the smart value in the "Link issue to" expression in the image below. But the goal would be: Instead of linking tickets mentioned in comments, we'd link tickets by each ticket's Epic assignee. (Which as you say, seems more complicated and may require chaining smart values in, say, an Advanced Branch. At least, that's where my head's at!)

Most of the examples I find in the Community forums similar to this have to do with auto-linking issues from comments.

Thanks again for the response!

[Bill Sheboy]

Thanks for clarifying, Dillon. The outcome you note is a common case...it is the details where it gets interesting implementing with rules.

My recommendation would be to first try to answer the questions below to understand how many rules you need and what triggers could fire them. 

Then try doing this incrementally in rules, such as

• having the version creation also create the release story,
• having the epic assignment to a version then create the subtasks in the release story, and
• divide-and-conquer approach: when a non-release story is added to an epic (or version), "walk up and then down the issues" using JQL branching to link just that story to the release story's subtask.  Edits to epic or version would be a different rule.

Here are those questions, and some possible assumptions.  Please adjust to you needs before trying the next rules:

1. When do you create versions/releases? Assumption: you do this first, and you have a rule to create a release story triggered on version create.
2. When do you add a Product Beneficiary to an epic? Assumption: when the epic is created; perhaps it is even a required field.
3. Can an epic have multiple Product Beneficiaries?  Assumption: no.
4. When do you associate versions/releases to epics? Assumption: this happens during or after epics are created.
5. Can an epic be associated to multiple versions/releases? Assumption: no; just one.
6. Can the version/epic for a epic change? Assumption: no.
7. When are stories associated to an epic? Assumption: this happens during or after story create.
8. When are stories associated to a version/release. Assumption: this happens during or after story create.
9. Can the version or epic for a story change? Assumption: no.
10. Can the version/release for a story in an epic be different than the epic's value? Assumption: no.