Question regarding hierarchical field synchronizations to downstream issues

Question

We are implementing a hierarchical field-synchronization pattern in Jira Cloud and would like guidance on the recommended approach (native automation vs other supported mechanisms) and any pitfalls we should be aware of.

Hierarchy Setup

Our Jira issue type hierarchy is configured as follows:
Initiative (top level)
Project Epic (child of Initiative)
Epic (child of Project Epic)
Story / Technical Story / Defect (child of Epic)

We use a custom single-select field called Portfolio Project Name (PPN) that is conceptually owned by the Initiative.
Field Governance Model
PPN is editable only on Initiative
PPN is visible as read-only on: Project Epic, Epic, Story, Technical Story, etc
Downstream issues should always reflect the Initiative’s PPN value

Target Behavior

When the PPN value is changed on an Initiative:
The new PPN value should cascade automatically to:
All child Project Epics
All Epics under those Project Epics
All Stories / Technical Stories / etc under those Epics

When hierarchy changes occur (e.g.):
A Project Epic is moved to a different Initiative or
An Epic is moved to a different Project Epic
The downstream issue(s) should automatically inherit the PPN from their new Initiative.

What We’ve Tried
Jira Cloud native automation rules using:
“Field value changed” triggers
“Parent changed” triggers
Lookup issues and branching

We are encountering limitations around:
Deep multi-level hierarchy traversal
Branching across multiple lookup result sets
Ensuring consistency when hierarchy changes occur

What I am needing to understand
Is this cascading field-inheritance pattern something Atlassian recommends implementing via Jira Cloud Automation, or are there known limitations at this hierarchy depth?
Are there best practices for:
Multi-level hierarchy traversal
Preventing partial updates or missed descendants
Are there product-native features (current or on the roadmap) that better support this use case?

Are there gotchas around:
Screen configuration
Field contexts
Read-only behavior
Automation recursion or performance
We’re looking for guidance on the cleanest, most supportable solution in Jira Cloud.

Daniel Turczanski · Answer

Hi @David Whitlock , why do you need field inheritance like that in Jira? As you can see there are a lot of edge cases to cover to maintain data accuracy over time.

If you share your use cases maybe people here are able to come up with solutions that don't require field syncing across the hierarchy.

David Whitlock_cecqw7 · Answer

@Aaron Pavez _ServiceRocket_ I did and it looks like the below. The problem I was having was that when the Initiative changed the PPN the child (Project Epic) reflected that change, but any children and grandchildren of the Project Epic did not get updated

Trudy P Claspill · Answer

Hello @David Whitlock

You will need multiple rules.

* when the PPN field is changed in the Initiative and you want it to cascade to all the children
* when an item is moved under a different parent and its PPN needs to be reset for the moved item and its children.

In both cases we are going to leverage the portfolioChildIssuesOf() JQL function to get all the children under a specific issue.

https://support.atlassian.com/jira-software-cloud/docs/search-for-advanced-roadmaps-custom-fields-in-jql/#Child-work-items

For the first rule you can use a rule like this:

TRIGGER: Field value change
  Field: PPN
CONDITION: Field value
  Field: Issue Type
  Condition: equals
  Value: Initiative
FOR EACH: Related Issue/JQL
  JQL: issue in portfolioChildrenOf("{{triggerIssue.key}}"
    ACTION: Edit Work Item
      Choose field: PPN
      Value: {{triggerIssue.PPN}}

This rule will catch the change of PPN at the Initiative level and cascade through all child levels all the way down through subtasks. If you want to exclude an issue type from being updated modify the JQL to include:

and issuetype not in (<comma separated list of issue types>)

For the second rule you need to detect a change in the Parent field, then get the PPN value from the new parent to reset the current issue, and cascade that change down to children of the current issue.

TRIGGER: Field value change
  Field: Parent
ACTION: Lookup Work Item
  JQL: issue = {{triggerIssue.parent.key}}
ACTION: Create Variable
  Name: parentPPN
  Value: {{lookupIssues.first.PPN|""}}
ACTION: Edit Work Item
  Choose field: PPN
  Value: {{parentPPN}}
FOR EACH: Related Issue/JQL
  JQL: issue in portfolioChildIssuesOf("{{triggerIssue.key}}"
    ACTION: Edit Work Item
      Choose field: PPN
      Value: {{parentPPN}}

I have not thoroughly tested this yet. I know that we can't directly access the value in the Trigger Issue's Parent without first changing focus to the parent issue, which I do with the Lookup Issue action. The value is then stored in a variable for later use. If there is no value in the PPN of the parent the variable should be set to an empty string.

I recommend you set up some test issues, perhaps in a separate test project, and test out these rules thoroughly first before activating them against your production data.