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

Inheriting fields from Initiative to Story Level

Jamie Stanczyk

Within our Jira Platform, I am trying to create an automation that allows our top level work item of Initiative to trickle down information to already created Epics, and further down Stories/Tasks.

I have a rule (rule 1) already working for when an Initiative field is updated, so for example description and due date, that the Children (in this case Epic), will copy the Initiative information.

Now here is where I have difficulty. Since you cannot nest a branch within a branch (if you can, please let me know), I cannot get the tasks/stories of the initiatives to inherit the Initiative fields. I tried creating a separate automation (rule 2) to where when the Epics fields are updated, based on the rule 1, it would update the stories/tasks, but it does not recognize any change happening.

Please let me know if you have any suggestions or solutions.

Thank you!!

Accepted answers

All comments

Brant Schroeder

@Jamie Stanczyk what are you using to identify the work item that will be updated? If it is everything under the initiative I would suggest using a JQL query that gets all the work item and updates them. Using issuekey in portfolioChildIssuesOf("WI-001") would provide all of the work items under the initiative and then you could run the update on all them or branch by type.

Jamie Stanczyk

Brant, thank you for the super quick response. Unfortunately, this needs to be a generic automation for any initiative created, whether it is existing or for future initiatives to be created.

In the meantime though, using your above suggestion should work perfectly for all existing initiatives within the space. Thank you!

Trudy P Claspill

Hello @Jamie Stanczyk

EDIT: the function name came out wrong via autocorrect. i have corrected it.

In your branch where you would use that JQL you would use a smart value, not an explicit issue key. Assuming the rule is triggered by a change on the Initiative you would use

issue in portfolioChildIssuesOf("{{trigger.Issue.key}}")

To ensure the rule copies data only when an Initiative is changed you should add a Condition after the trigger to check that the issue type is Initiative.

Germán Morales

Hi Jamie,

Trudy’s approach is the direction I would take as well: avoid nested branches and use a JQL branch that returns all descendants of the Initiative.

One important detail: inside the branch, the “current issue” becomes each child issue returned by the JQL. So when copying values from the Initiative, make sure you reference the trigger issue, not the branched issue.

For example, if the rule is triggered by an Initiative field update:

1. Trigger: Field value changed
2. Condition: Issue type = Initiative
3. Branch: JQL
issue in portfolioChildIssuesOf("{{triggerIssue.key}}")
4. Inside the branch:
- Edit issue
- Copy values from {{triggerIssue}} into the child issue fields

For example:

- Description = {{triggerIssue.description}}
- Due date = {{triggerIssue.duedate}}

This avoids the need for a branch inside a branch.

Also, your second-rule approach may not fire because changes made by one automation rule do not always trigger another automation rule unless rule chaining is explicitly allowed in the automation settings. Even when it works, chained automation can become harder to debug.

So I would keep this as one Initiative-triggered rule if possible, with a JQL branch over all child issues.

Trudy P Claspill

@Germán Morales

For many fields it is not necessary to use smart values to copy from the trigger issue. Consider the flow of selections shown below:

Screenshot 2026-05-22 at 9.03.09 AM.png

Screenshot 2026-05-22 at 9.05.39 AM.png

Germán Morales

Thanks Trudy, that makes sense.

Good clarification: for supported fields, using the “Copy from trigger issue” option in the Edit issue action is cleaner than typing smart values manually.

I would still use smart values when the field is not available in the picker, or when the value needs to be transformed before being copied.

Also, I corrected the JQL function name in my answer to:

issue in portfolioChildIssuesOf("{{triggerIssue.key}}")

Trudy P Claspill

The function name came out wrong via autocorrect in my reply. i have edited the reply to correct it.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud