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; } } }

Can Automation Rules create a work item child issues in another project?

Tracy A Stimac

Is it possible to configure automation rules to create a set of standard child issues in a different project from the parent work item. In the scenario we would have Project AA (PAA) create an Epic work item (PAA-1). Project BB would have a board to view Project AA Epic work item (PAA-1). The automation rule behavior we would like is that manually triggering an automation rule on the EPIC (PAA-1) from the Project BB board would create the children work items within Project BB (PBB-#) and with the Parent as PAA-1.

Is there an option in the automation rule 'Create Issue' action to define the Project as the current project backlog/board?

There are two default options for 'Same Project'; drop down values of 'Same Project' and 'Same Project as Trigger? Both appear to create the child issue within Project AA where the Epic PAA-1 resides. What is the difference between these two options?

Accepted answers

David Friedrich

Hi @Tracy A Stimac , hope you are well.

Let's brake your questions down and look at them one by one:

1. Can automation rules create child issues in a different project from the Epic (parent)?
Yes, but not with a direct parent-child (Epic link) relationship if the parent (Epic) and the child issues are in different projects — this is currently not possible.

You can use automation rules to create issues in a different project. However, you cannot link child issues to an Epic in another project via the standard Parent or Epic Link field due to Jira's project scoping limitations. As a workaround, you could:

- Create the issues in Project BB.
- Use labels, custom fields, or issue links (e.g., "relates to") to associate them with the Epic in Project AA.
- OR consider moving to Advanced Roadmaps (if available in your Jira plan), which supports cross-project hierarchy and tracking.

2. Can the "Create Issue" action define the project as the board/backlog currently being viewed?
No — the automation engine doesn't “see” the board the user is on. It only knows about the project the issue belongs to (i.e., the Epic’s project). Boards in Jira are views over projects; they don’t define context for automation rules. The automation rule can only access data from the trigger issue’s project (Same project as trigger issue) or a specific named project you select manually.

3. What’s the difference between Same project and Same project as trigger issue?
Same project - The issue is created in the project where the automation rule is being configured. It's usually used in global/multi-project rules.
Same project as trigger issue - The issue is created in the same project as the issue that triggered the rule (i.e., the Epic in your case, PAA-1).

In most single-project automation rules, these behave the same. But in global/multi-project rules, the distinction matters.

Hope that helps! Have a good weekend,
David

All comments

David Friedrich

In most single-project automation rules, these behave the same. But in global/multi-project rules, the distinction matters.

Hope that helps! Have a good weekend,
David

Tracy A Stimac

Thanks for confirming the Epic/Child relationship cannot be created across projects. That's what we were seeing but wanted to make sure we weren't missing an approach.

John Funk

Hi Tracy - Just trying to understand the exact scenario. It doesn't matter if you create a work item on a board or using the Create button, you are just doing a Create action. So, there is not a current board function that would know what the project is - mainly because a board can be linked to multiple projects.

If you want to hard code the Epic key as the parent when you create an issue in another project, then you can do that. For example, the rule would be based on a Create Work Item trigger in project BB, and then you could add an Edit Work Item action for the Parent field and hardcode PAA-1 as the Parent.

Is that the scenario? Or are you doing something else? And if so, can you provide a step by step use case?

Welcome!

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

Quick Links

Find more posts tagged with

cloud

automation