Help creating a simple automation rule to transition parent issues

Question

My configuration has Epics in one space, children of Epics we call Features in another space, and then children of the Features in each individual team space that performs the work on stories and tasks.  I am struggling to create an automation rule where when a child story from one space first moves to "Implementing" I want the parent issue (Feature) in another space to transition to "Implementing" from it's prior workflow status.

I can get it to work if my story and Feature are in the same space, but my automation will not work across spaces for some reason.  I am creating the rule in the global admin area and calling out the spaces that are in play.

Joshua Brock _ Seibert Group_ GmbH · Answer

Hey @James George Lance_ Jr ,

Cross-space / cross-project automation like this is a known sore spot, in that rules scoped to "for: Parent" generally need the parent and child to live in projects the rule has been explicitly granted access to, and global-admin-level rules can behave inconsistently depending on how the trigger and the "for: Parent" branch resolve issue context across project boundaries.

Just a suggestion on a few things worth checking before you go further:

Confirm the rule actually has both projects added to its scope (not just referenced in a condition)...this is the single most common cause of "works same-project, fails cross-project"

Check the audit log for the specific run where it should have fired, as it'll usually show whether the trigger matched, but the branch found no parent, or whether the trigger never fired at all

Try replacing the implicit "for: Parent" branch with an explicit JQL/lookup step that fetches the parent by key, to rule out a context-resolution issue

Stepping back a tad in what you're describing (Epics in one space, Features as their children in another, Stories/Tasks owned by individual team spaces) is essentially a manually-built SAFe-style hierarchy (Epic → Feature → Story) spread across project boundaries, held together with custom automation. That's exactly the kind of setup that becomes increasingly fragile as you add teams, because every new space means another set of rules to scope, test, and maintain.

If your organization is heading toward (or already running) a scaled agile / SAFe model, Agile Hive takes a different approach to this problem entirely:

It enforces the full Portfolio Epic → Feature → Story hierarchy as a native Jira data model, so parent/child status relationships aren't something you have to wire up yourself with automation rules

Cross-team dependencies surface on a dedicated planning board rather than being inferred from issue links and custom rules

Everything stays inside Jira as a single system of record. There is no second platform, no sync jobs, no per-space rule maintenance

It's built specifically for multi-team, multi-project coordination at the ART/Program level, which sounds close to what you're managing today...apologies if I'm reading more into that.=

It's worth a look if the automation maintenance here is starting to feel like it's outgrowing what hand-rolled rules can reliably do. There's a free trial on the Atlassian Marketplace.

And just in full disclosure, I work at Seibert Group, the team behind Agile Hive.

Hope this helps, and best of luck!

Joshua 
Content Writer & US Representative 
Agile Hive and Aura Apps (products of Seibert Group GmbH)

Trudy P Claspill · Answer

Hello @James George Lance_ Jr

Can you show us all the details in the run log for a time when the rule ran and you expected it to work and it did not?

Also, what are the project types for the projects in scope for the rule? Click the ellipsis button next to each project's name in the navigation panel on the left and tell us what the last two lines in each pop-up say.

C.Faysal {CFcon} · Answer

Hi @James George Lance_ Jr

can you please confirm this rule has both Spaces scoped correctly?

afterwards we can continue the analysis

thank you

regards