nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Automation Rule Advice. Prevent duplicate Initiatives when multiple impacted-area rules fire (fan ou

Dan Leatherwood

Our goal is to create an Automation for Jira DC that creates one Initiative and then fans out multiple Epics/Stories across different projects from a single request, based on several Yes/No “impacted area” fields, while avoiding duplicate Initiatives.

General Rule Information Jira Data Center xxxx Impacted Areas = 11 binary yes/no select lists created as 11 separate fieldsCustom Field 18503 = “Changes Needed.” Customfield_11902 = Parent Link (Epic → Initiative)Customfield_10006 = Epic Link (Story → Epic)ProjectId 28100 = Strategic InitiativesProjectId 30300 = impacted area delivery project

We worked with support for guidance and landed on the best path, which was more than one rule. We so far have:

The framework for the rule for when there is only a single impacted area we have created looks like:

Trigger: Issue is transitioned from status ID 3 to status ID 10001.
Condition 1: customfield_18503 on the request = “Yes” (e.g., “Changes Needed = Yes”).
Condition 2 (sub‑branch): If customfield_18700 (Requesting Business Area) = “ACSIS History”, then:
- Create a Story in project 30300, copy summary/description from the request, and link it back to the request via issue link type inward:10000.
- Log Story: createdIssue.key in the audit log.
Create Initiative:
- Create an Initiative in project 28100 (issue type 12705), copy summary/description from the request, and link it back to the request via issue link type inward:10003.
- Log Initiative: createdIssue.key.
- Store the Initiative key in a smart variable called InitiativeKey.
Create Epic (linked to Initiative):
- Create an Epic in project 30300 (issue type 10000), copy summary/description from the request, and set customfield_16200 from the request’s customfield_16200.
- In advanced fields, set customfield_11902 (likely Parent Link) to InitiativeKey so the Epic is parented to the Initiative.
- Log Epic: createdIssue.key.
Create Story (linked to Epic):
- Create a Story in project 30300 (issue type 10001), copy summary/description from the request, set Epic Link (customfield_10006) to the just‑created Epic’s key (createdIssue.key from the Epic step), and copy customfield_16200 from the request.
- Log Story: createdIssue.key.

Note / known issue (not intentional): In the single-impacted-area framework above, the ACSIS History sub-branch creates a Story, but the rule then continues on to create the Initiative → Epic → Story chain as well. That means when customfield_18700 = "ACSIS History" we currently end up with two Stories (one linked to the request and one linked to the Epic). This is not the intended behavior—we want only one Story path to run (either “story-only” or the Initiative/Epic/Story path), so we’re likely missing an ELSE / stop / guard structure there.

Where we need help:

We are struggling to convert this into a rule for multiple impacted areas.

Example: If Impacted Area A = Yes and Impacted Area B = Yes on the same request, we expect 1 Initiative + 2 Epics + 2 Stories, but we currently get 2 Initiatives + 2 Epics + 2 Stories.

We have considered:

Eleven modified clones of the above rule, but avoiding non-duplication or false positives is challenging. When a single request has 2+ impacted areas = Yes, multiple rules trigger, and each creates an Initiative, so we end up with duplicate Initiatives for the same request. Since our goal is one Initiative per request issue, we need a guard so that even if multiple impacted-area rules fire for the same request transition, only one rule creates the Initiative and the others reuse its key. We are primarily trying to avoid creating multiple Initiatives for the same request when 2+ impacted areas are marked Yes.
This is where support recommended using a custom field with Lookup Issues from the Jira Automation Actions Landing Page, but we are struggling to implement that correctly.
We also considered implementing a single, very large and complex rule, but we have not yet gotten it to work, and that would be a step beyond our current level of expertise.

Questions:

If the best approach is a guard field/flag on the request, what do people typically store (e.g., Initiative key vs boolean), and how do they avoid race conditions?
We are also open to recommendations for a cleaner approach altogether.

Rule JSON

If it can help, the full JSON of our current progress is:

Accepted answers

All comments

Bill Sheboy

Hi @Dan Leatherwood

Rather than posting a text description or partial JSON for a rule, I recommend posting:

an image of the complete rule in a single image for continuity
an image of the audit log details for the execution
explain what is not working as expected for that specific rule

Those will provide better context to help understand the symptoms. Thanks!

Next, I am having trouble following your exact scenario's variations. It may help to provide a GIVEN ... WHEN ... THEN ... description of the scenario, and some specific examples of any variations.

Until we see those, you have more limitations with Jira Data Center automation than with Cloud. A couple of different approaches to create multiple levels of issues based on a single event / trigger are:

Use chained rules, where the actions of one rule trigger the next level down to do more work. In the "downstream" rules, enable the "Allow Rule Trigger" option in the details at the top. Rule chains like this can be challenging to get right and to maintain.
Given the number of issues to be created, you could try creating a dynamic JSON expression using conditional logic for the lower levels, and use a single Send Web Request action to call the REST API endpoint to bulk-create issues.

Kind regards,
Bill

Ben Spillane

UPDATE:

My I offer my sincere apologies @Dan Leatherwood. I've overlooked the substantial difference in automation capabilities between Jira DC and Cloud.
My suggested solution does require advanced features of Jira Cloud automations, such as:
- Advanced branching (e.g. For each: Smart value)
- Trigger conditions
As originally noted: Smart value syntax should be checked in your environment as the required notation depends heavily on your specific data types, use of chained function, combination of data structures, etc.
As originally noted: My responses were based on my real world experience in implementing advanced (native) Jira automations.
I used AI to augment my genuinely original thoughts and concepts to provide additional context and a higher level of professional formatting

Your current challenge stems from a synchronization and duplication issue inherent in Jira’s event-based automation. Here is a breakdown of the core problem:

The "Multiplying Parent" Bug: Because you are currently using multiple rules (or multiple independent branches) to check for "Impacted Areas," each "Yes" selection triggers a separate creation flow. Since these flows do not "talk" to each other, they each create their own Initiative, resulting in a fragmented hierarchy instead of a unified one.
Race Conditions: Even if you try to use a "flag" field to check if an Initiative already exists, Jira Data Center's high-speed execution means two rules can check that flag at the same millisecond, see it as "Empty," and both proceed to create a duplicate Initiative.
Logic Redundancy: Your current structure treats specific areas (like ACSIS History) as "special cases" with different branching logic. This has led to unintended "double Story" creation because the rule doesn't have a clear "Exit" or "Else" path once a specific condition is met.
Maintenance Overhead: Managing 11 different fields via 11 different sets of hard-coded blocks is prone to human error. Every time a project ID or a field name changes, you currently have to update the automation in multiple places.

The Shift in Strategy

The proposed JSON-driven solution shifts the rule from Hard-Coded Logic to Data-Driven Processing. Instead of telling Jira what to do for every specific field individually, you are giving Jira a map (the JSON) and a single set of instructions on how to read that map.

This ensures:

The Initiative and Epic are created exactly once at the start.
The Stories are "fanned out" dynamically based on the trigger data.
The entire tree is linked correctly using variables (InitKey, EpicKey) that persist throughout the single execution.

This structure allows you to use a single Create variable action at the start of your rule to define the entire "Blueprint" for the request.

1. Proposed JSON Data Structure

Here is how that schema would look. It separates the "Global" parents (Initiative/Epic) from the "Conditional" children (Impacted Areas).

{
  "hierarchy": {
    "initiative": { "project": "28100", "typeId": "12705", "prefix": "INIT:" },
    "epic": { "project": "30300", "typeId": "10000", "prefix": "EPIC:" }
  },
  "impactedAreas": {
    "customfield_18700": { 
      "name": "ACSIS History", 
      "project": "30300", 
      "typeId": "10001", 
      "prefix": "STORY:" 
    },
    "customfield_18701": { 
      "name": "Billing Systems", 
      "project": "30300", 
      "typeId": "10001", 
      "prefix": "STORY:" 
    }
  }
}

2. The Logic Workflow

UPDATE:

The low level implementation logic for this pattern requires features of Jira cloud automation.
I've removed original details to avoid confusion.

I have used this general data-driven blueprint pattern previously to manage scenarios that would otherwise require dozens of separate automation rules or incredibly deep, nested conditional logic. By treating the JSON as a configuration layer, you decouple the "what" (your business data) from the "how" (the Jira automation engine). This makes the system significantly easier to scale—adding a 12th or 13th impacted area becomes a simple text update rather than a structural rebuild of the rule.

A quick note on implementation: While the logic and JSON structure provided above follow proven architectural guidelines for Jira Cloud Jira Data Center, please treat this as a conceptual framework. This hasn't been pulled from a live, finished production environment, so you will want to validate the specific field IDs and smart value syntax within your own environment to ensure it handles your specific global transitions and project permissions correctly.

Regards,

Ben

Dan Leatherwood

Ben, thanks for this indepth analysis.

Here is a different description of what we are trying to accomplish:

Trigger: Requestor moves Request issue to Submitted/Done on the Request Project

Automation:

If two or more areas are impacted (Changes Needed = yes)

1. Create an initiative (Strategic Initiative project)
2. Create an epic on each affected area's project
3. Create a story on each affected area's project
4. Properly "link" each parent/child (i.e., initiative linked to request (relates to), epic linked to initiative, story linked to epic)

2. If only one area is impacted (Changes Needed = yes)

A. If the impacted area is the same as the Requesting Business Area:

Create story on impacted area's project

Properly "link" story to the request issue (relates to)

B. The impacted area is NOT the same as the Requesting Business Area:

1. Create the initiative
2. Create an epic on the affected area's project
3. Create a story on the affected area's project
4. Properly "link" each parent/child (i.e., initiative linked to request, epic linked to initiative, story linked epic)

Dan Leatherwood

Bill,

Please see my reply to Ben above to see if that helps better describe the use case.

Ben Spillane

Hi @Dan Leatherwood

Does this refactored interpretation below align with your requirement(s)?

If it's getting close I could throw together a working example to demonstrate.

The goal is to dynamically choose between two structural patterns when the request is submitted and automation rule triggered:

Pattern A: The Full Hierarchy (Standard Fan-Out)
Triggered if: 2+ areas are impacted OR 1 area is impacted that differs from the Requesting Business Area.
- Create 1 Initiative (Linked to Request).
- Create n Epics (Linked to Initiative) — one per impacted area.
- Create n Stories (Linked to their respective Epics).

Pattern B: The Direct Link (Simplified Path)
Triggered if: Exactly 1 area is impacted AND it is the same as the Requesting Business Area.
- Create 1 Story (Linked directly to Request).
- Note: No Initiative or Epic is created in this scenario.

How the JSON Strategy Handles Both Patterns

Using the Data-Driven JSON approach mentioned earlier, you can handle these logic branches cleanly within a single rule:

Count the Impacts: Use a smart value to count how many "Yes" selections exist.
The Conditional Guard:
- If the count is 1 and the area matches the business area, the rule executes a simple "Create Issue" for the Pattern B Story.
- Otherwise, the rule proceeds to the Pattern A logic: creating the Initiative first, then entering the JSON-driven loop to fan out the Epics and Stories.

By defining the logic this way, you avoid "race conditions" because the decision of which pattern to follow is made at the very start of the rule execution, before any issues are created.

Bill Sheboy

Thanks for the additional information on your scenario, @Dan Leatherwood as it seems quite challenging to solve with Jira Data Center (DC) automation...let alone with Cloud.

One way to possibly solve the variable number of issues for your impact areas is using multiple rules and if / else blocks. This is needed because Jira DC does not have Advanced Branches. The general approach would be:

Create a rule with an Incoming Webhook Trigger, the purpose of which is to create one set of issues for an impact area. The impact area, and any relevant source issue data, are passed as custom data.
The second rule is based on your original one with the Issue Transitioned trigger. It would use a series of if / else blocks to decide and select which impact area / issues are needed. When one is detected, the block calls the first rule using the Send Web Request action, passing the necessary data.

This approach should eliminate duplicate Initiatives as the if / else blocks select only what is needed one-by-one before callout out to the other rule.

Although this approach may work, it may be brittle and complicated to maintain...particularly if something causes an error to interrupt the flow.

Bill Sheboy

Hi @Ben Spillane

What is the source of the information you are posting? As a reminder, when posting AI-generated content, the content should be validated and the source described in the text of the post. To learn more, please see the community guidelines:

https://community.atlassian.com/forums/custom/page/page-id/rules-of-engagement

Several things in the described approach do not exist in automation rules:

There is no interpretation of plain text from a variable as JSON in Jira Data Center (DC). There is limited support for converting text to JSON objects in Jira Cloud automation features.
A long-format iterator list iterator, as you show for the variable, cannot access data from outside scopes (i.e., issue data).
There is no generic function in automation rules to "get" an issue by key. Complete issues can be supplied from the trigger or branches, and issue data can be supplied from the Lookup Issues action or REST API endpoints via the Send Web Request action.
There is no Advanced Branch in Jira DC automation

Kind regards,
Bill

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

automation