Overview

This Automation rule will generate an epic for any team contained in the "Participating Teams" multi-select field when the initiative is transitioned into the "Create Tickets" status.

Prerequisites

“Participating Teams” Multi-Select Custom Field

In this model, each Jira project represents a team. The “Participating Teams” multi-select custom field identifies which teams\Jira projects will be doing work contributing to the completion of this initiative. Each value in this field needs to follow the convention below:

Rule Configuration

Trigger

Issue Transitioned

• Status: “Create Tickets”

Branch

Smart Value:

{{#issue.Participating Teams}}{{value.replaceall("(.*)(\()(.*)(\))","$3")}}{{/}}

Variable Name: {{project}}

Condition

Related Issues: Linked Issues

Link Types: “Is Supported By”

Matching JQL:

project = {{project}} and summary ~ "{{triggerIssue.summary}}"

Action

Create Issue

• Project: Same Project

• Issue Type: Epic

• Fields to Set

  • Copy Summary from Trigger Issue

  • Linked Issues

    • “Supports”

    • “Trigger” issue

• Additional Fields

  • { "fields": { "project":{ "key": "{{project}}" } } }

Open

The branch extracts the project keys from the “Participating Teams” field and stores the resulting list in the variable {{project}}

 

Open

The condition checks to make sure there is not already an issue created and linked with the same summary.

 

Notes

Cloud Only

This rule uses the "Advanced Branch" functionality to carry out a series of actions over a list; this has not been ported to Automation for Server\DC as of now. While the majority of this logic can still be used to create tickets, without the ability to iterate over a list in this way, you may be restricted to creating only one ticket at a time.

Identifying the Right Project(s)

Automation for JIRA Cloud will still not let you use a smart value in the "project" field of a "create issue" action (track request on JRACLOUD-78577). This means there are some additional steps needed to pick out the project(s) you want to create tickets in.

"Participating Teams" Field

The rule uses string matching to get the JIRA project key from a custom field. The logic used to parse the (potentially) multiple values and return an array of project keys is:

If you decide you want to use a different naming convention, be sure to modify the regex pattern "(.*)(\()(.*)(\))" accordingly.

Ticket Creation

Use "same project" value in the "Create Issue" action and then use the following JSON in the "Additional Fields" section:

Summary as Validator

This rule attempts to check for an existing ticket before creating a potential duplicate by looking for an unresolved ticket linked to the trigger issue in the same project with the same summary; a new ticket is only created in the event of no results found. If you do not want to programmatically define the summary, you can use any other combination that would result in "uniqueness" to do this. 

Common Modifications

Other Fields

Jira requires all issues to have a summary, and setting it to the same summary as the initiative helps teams remember what initiative they’re supporting as well as helping us prevent duplicate epics being created. However there are likely other fields on your initiatives that would make sense to be pushed down to child epics, like “Target Release Date” or “Initiative Lead”.

Trigger Changes

As designed, this rule is supporting an epic-refining process and so is triggered by a workflow transition. A common deviation would be to trigger the rule on updates to the "Participating Teams" field; this would automatically create a new ticket whenever a new "participating team" is identified.

Other Actions

When connected to an ITSM process, an additional action is often added to trigger a message to the recipient team to give them a heads up that a new escalation to them has occurred. This is usually done in the team's normal synchronous communications tool, such as Slack or Teams.

Projects for Not-Teams

As mentioned above, this rule is currently designed assuming a model where every Jira project represents a team. However as long as the naming convention is followed (or the regex is modified to suit your new model), you could use Jira projects to represent products, regions, or anything else that works for your organization.