7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics
Key Takeaways
- Branch rules alter the execution context of an automation rule, shifting operations from the initiating trigger issue to related work items such as Sub-tasks, Parent issues, Epics, Linked issues, or JQL query results.
- While inside a branch block, the smart value {{issue}} refers to the branched target issue, whereas {{triggerIssue}} preserves access to the original event issue that initiated the rule.
- Parent-child lifecycle synchronization (such as auto-closing an Epic when all child stories are Done, or transitioning a Story when all sub-tasks reach Done) combines branch rule iteration with the 'Related issues' condition.
- The 'Re-fetch issue data' action is essential when subsequent rule actions must evaluate freshly modified field values or workflow states that were updated by branches, post functions, or external apps during rule execution.
- Branch execution across multiple issues can run in parallel, and actions placed below/outside a branch block resume execution within the context of the original trigger issue.
7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics
Quick Summary: By default, an automation rule executes every action within the context of the issue that fired the trigger. However, enterprise business processes frequently span multiple related work items: closing an Epic when all child stories are completed, cascading security levels from parents to sub-tasks, or syncing resolution statuses across linked dependencies. Branch Rules allow administrators to shift the execution context to related issues, perform mutations, and return to the primary flow. Mastering branch topologies and understanding the vital role of the Re-fetch issue data action are core requirements for the ACP-120 exam.
Branch Rule Architecture & Context Switching
When a branch rule component is added to an automation rule, it creates a nested operational block. Inside this block, the engine's active context switches from the original Trigger Issue to the specified Branched Issue(s).
+-------------------------------------------------------------------------+
| BRANCH RULE CONTEXT TOPOLOGY |
+-------------------------------------------------------------------------+
| TRIGGER: Issue Transitioned (Story: ENG-101 -> 'Done') |
| Context: {{issue.key}} = 'ENG-101' |
| |
| | |
| v |
| +-------------------------------------------------------------------+ |
| | BRANCH: Parent / Epic (Context Switch) | |
| | Context inside branch: | |
| | {{issue.key}} = 'ENG-50' (The Parent Epic) | |
| | {{triggerIssue.key}} = 'ENG-101' (The Triggering Story) | |
| | | |
| | [Action: Check if all child stories are Done] | |
| | [Action: Transition Epic ENG-50 to 'Done'] | |
| +-------------------------------------------------------------------+ |
| | |
| v |
| RESUME TRIGGER CONTEXT: |
| Context outside branch: {{issue.key}} = 'ENG-101' |
| [Action: Add comment to ENG-101: 'Parent Epic verified and closed'] |
+-------------------------------------------------------------------------+
Accessing the Trigger Issue: {{triggerIssue}} vs. {{issue}}
A frequent point of confusion on administrative exams is differentiating between {{issue}} and {{triggerIssue}}:
{{issue}}(Active Context Issue): Represents whatever issue the rule is currently evaluating. Outside a branch, it is the trigger issue. Inside a branch,{{issue}}dynamically shifts to represent the child sub-task, the parent epic, or the linked issue currently being processed.{{triggerIssue}}(Original Event Issue): Retains a permanent, immutable reference to the issue that initiated the rule, regardless of how deeply nested the branch is. For example, if a branch on a sub-task needs to copy a comment from the parent story that triggered the rule, it references{{triggerIssue.description}}.
Branch Target Types in Jira Cloud
Administrators can configure branch rules across several relational dimensions:
| Branch Type | Target Issues Evaluated | Common Administrative Use Case |
|---|---|---|
| Sub-tasks | All sub-tasks belonging to the trigger issue. | Cascading field updates (e.g., Fix Version, Security Level, Assignee) from parent to children. |
| Parent / Epic | The immediate parent of the trigger issue (the standard issue for a sub-task, or the Epic for a story/task). | Auto-updating parent progress, checking completion criteria, syncing comments upward. |
| Children (formerly "Issues in Epic" / "Sub-tasks") | The issues whose Parent is the trigger issue: an epic's stories, tasks, and bugs, or a standard issue's sub-tasks. | Re-opening child items when an Epic is reopened, or closing all children during cancellation. |
| Linked Issues | Issues connected to the trigger issue via specific Issue Link types (e.g., blocks, is blocked by, clones, relates to). | Automatically notifying assignees of blocked issues when the blocker issue transitions to Done. |
| JQL Search Results | Issues returned by a JQL query (which can embed smart values), subject to automation service limits. | Batch processing related tasks across multiple projects (e.g., updating all open issues in the same sprint). |
| Current Issue (Branch) | Creates an isolated branch operating on the trigger issue itself. | Structuring parallel execution paths or isolating conditional logic on the trigger item. |
Enterprise Synchronization Pattern: Auto-Closing Parent Epics
One of the most widely implemented automation patterns in agile organizations is automatic epic completion: when an engineer closes the last open story in an Epic, the automation rule evaluates whether all sibling stories are also complete, and if so, automatically transitions the parent Epic to Done.
1. TRIGGER: Issue Transitioned
- To status: Done
- Condition: Issue Type != Epic (Only run for child issues)
2. CONDITION: Issue has a Parent / Epic
- Validates that the issue is actually linked to a parent epic.
3. BRANCH: Parent / Epic
- Context switches to the parent Epic.
4. NESTED CONDITION (Inside Branch): Related Issues Condition
- Related issues: 'Issues in epic'
- Condition: 'All match specified JQL'
- Matching JQL: statusCategory = Done
5. ACTION (Inside Branch): Transition Issue
- Destination Status: Done
- Resolution: Done
Why the Related Issues Condition is Critical
Notice Step 4: The rule does not simply transition the Epic immediately upon receiving the event from one child story. It uses the Related Issues Condition inside the Epic branch to verify that ALL sibling issues in the Epic belong to the Done status category (statusCategory = Done). If even one sibling story remains in To Do or In Progress, the condition fails inside the branch, short-circuits, and leaves the parent Epic open without running unnecessary actions.
Linked Issue Synchronization: Unblocking Dependencies
Another essential enterprise pattern is dependency unblocking using the Linked Issues branch:
+-------------------------------------------------------------------------+
| DEPENDENCY UNBLOCKING WORKFLOW |
+-------------------------------------------------------------------------+
| TRIGGER: Issue Transitioned (Target Status: 'Done') |
| |
| BRANCH: Linked Issues |
| - Link Type: 'is blocked by' |
| |
| [Condition inside branch: statusCategory != Done] |
| |
| [Action inside branch: Add Comment] |
| "Good news! Blocker issue {{triggerIssue.key}} ('{{triggerIssue. |
| summary}}') has been resolved. This issue is now unblocked." |
| |
| [Action inside branch: Transition Issue -> 'In Progress'] |
+-------------------------------------------------------------------------+
In this workflow, when PROJ-100 (which blocks PROJ-200) is resolved, the branch targets PROJ-200 via the is blocked by link. The comment on PROJ-200 utilizes {{triggerIssue.key}} to explicitly inform the team which blocking ticket was just resolved.
The "Re-fetch Issue Data" Action & Caching Nuances
A critical technical concept tested on the ACP-120 is how Jira Cloud caches issue data during rule execution. When an automation rule fires, the engine snapshots the issue's field values into an in-memory execution context.
[Rule Execution Start: Memory Snapshot Cached]
Issue: PROJ-101 | Status: In Progress | CustomField_Cost: 100
|
v
[Step 1: Branch / External Webhook Mutates Issue in Database]
Database updated: CustomField_Cost is now 250
|
v
[Step 2: Subsequent Action reads {{issue.customfield_Cost}}]
WITHOUT Re-fetch: Reads STALE CACHE value (100) -> WRONG / FAILS!
WITH Re-fetch: Reloads latest database record (250) -> ACCURATE!
When is Re-fetching Mandatory?
- After Branch Mutations: If a branch modifies an issue, and subsequent actions outside or downstream in that branch need to evaluate those updated fields, the engine may read the pre-branch cached snapshot unless refreshed.
- Following Workflow Post Functions: If a rule transitions an issue, and that transition triggers a workflow post function (or a third-party app script) that calculates values or updates resolutions, the automation engine's cached copy does not reflect those changes.
- External API Updates: If an action invokes an external service via the Send web request action that modifies the Jira issue via the REST API.
How to Implement
Insert the Re-fetch issue data action immediately after the branch or transition step and before any downstream conditions or smart values that evaluate the modified fields. The action forces the automation engine to invalidate its local memory cache and execute a fresh SQL/index reload of the issue entity from the Jira database.
A Jira Administrator is designing a rule to automatically close an Epic when all of its child user stories and bugs reach a terminal status. The rule triggers on 'Issue Transitioned' to 'Done'. After verifying the issue has a parent Epic, the rule branches to 'Parent / Epic'. What component must be placed immediately inside the parent branch before the transition action to prevent the Epic from closing prematurely when only the first child story is finished?
An automation rule is configured to streamline software releases. When an issue transitions to 'Deployed to Staging', Step 1 transitions the issue, which triggers a backend app post function that calculates and populates a custom field 'Staging Verification Hash'. Step 2 of the automation rule is an Advanced Compare Condition that checks if '{{issue.Staging Verification Hash}}' is not empty before firing a webhook to a testing tool. In production, Step 2 consistently fails because the hash appears empty to the automation engine, even though viewing the issue in the Jira UI shows the hash is populated. How should the administrator resolve this discrepancy?
An administrator creates an automation rule that runs when an incident ticket is created. The rule contains a branch that iterates through all issues connected by the link type 'is caused by'. Inside this branch, the administrator needs to write an automated comment on each linked issue stating: 'Investigating incident [Key] assigned to [User]', where [Key] and [User] reflect the incident that triggered the rule, NOT the linked issue. Which smart values must be used in the comment action inside the branch?