Study guide
7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics
Atlassian Certified Professional - Jira Administration for Cloud ACP-120
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Blueprint & Jira Cloud Fundamentals
1.1 ACP-120 Exam Structure, Blueprint & Testing Strategy 1.2 Jira Cloud Architecture, Products & Admin Hierarchy
2 Chapter 2: Organizations, Managed Accounts & Global Access
2.1 Atlassian Organizations, Domain Verification & Managed Accounts 2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies 2.3 Site Access, Product Access Tiers & Global Permissions 2.4 User Directory Architecture: Groups vs. Project Roles
3 Chapter 3: Project Permissions & Issue-Level Security Schemes
3.1 Permission Scheme Mechanics & Critical Project Permissions 3.2 Permission Troubleshooting, Additive Permissions & Permission Helper 3.3 Issue Security Schemes, Security Levels & Access Containment
4 Chapter 4: Project Configuration, Types, Versions & Boards
4.1 Company-Managed vs. Team-Managed Project Architecture 4.2 Project Templates, Project Keys & Project Categories 4.3 Project Components, Component Leads & Default Assignees 4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving 4.5 Scrum and Kanban Board Configuration, Board Filters & Columns
5 Chapter 5: Issue Types, Custom Fields, Screens & Schemes
5.1 Standard vs. Sub-task Issue Types & Issue Type Schemes 5.2 Custom Field Types, Global vs. Project Contexts & Options 5.3 Field Configurations, Renderers, Hiding & Required Fields 5.4 Screens, Screen Schemes & Issue Type Screen Schemes
6 Chapter 6: Workflows — Company-Managed and Team-Managed
6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions 6.2 Transition Rules: Conditions vs. Validators 6.3 Post Functions, Execution Order & Resolution Management 6.4 Workflow Schemes, Editing Active Workflows & Status Migration 6.5 Team-Managed Workflows, Statuses & Workflow Rules
7 Chapter 7: Jira Cloud Automation
7.1 Automation Engine, Rule Architecture & Event Triggers 7.2 Automation Conditions, Smart Values & String/Date Expressions 7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics 7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
8 Chapter 8: Notifications, Events, Personal Settings & Mail Handlers
8.1 Jira Events, System Events & Notification Schemes 8.2 Notification Recipients, Custom User Fields & Deduplication 8.3 Team-Managed Notifications, Personal Settings & Troubleshooting Missing Email 8.4 Mail Handlers: Creating Issues and Comments from Email
9 Chapter 9: JQL, Filters, Dashboards & Bulk Operations
9.1 JQL Fundamentals, Clauses, Operators & History (WAS / CHANGED) 9.2 Advanced JQL Functions & Dynamic Date Searches 9.3 Filter Permissions, Shared Filters & Filter Subscriptions 9.4 Dashboard Layouts, the Default Dashboard, Sharing & Essential Gadgets 9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
10 Chapter 10: System Administration
10.1 Global UI Features: User Defaults, Look and Feel, Announcement Banner & Default Dashboard 10.2 Statuses, Resolutions, Priorities & Sub-tasks: Global Configuration 10.3 Global Settings: Time Tracking, Issue Linking, Attachments & Application Links 10.4 System Backup, Restore & Data Import
7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics
Key Takeaways Explain This Topic AI
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.
Last updated: September 2026
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.