Dynamic Dependency Rollups: Taking Prioritization Further with JFL Script

[#1]

In our last two posts, we covered how our team uses formulas to surface delivery risks and catch data gaps directly in Jira. Combining multiple fields in a single formula gave us a real-time health matrix that transformed our standups.

But as our work became more interconnected, we hit a wall: JFL is great at checking a single row, but it gets stuck when you need to dig through a list of subtasks and child work items.

A parent story might look completely fine on the surface—it has an assigned owner, clear estimates, and an upcoming due date. But what if one of its subtasks is blocked or falling behind? Standard spreadsheet formulas can't automatically dig into the list of these child work items and count up the hidden risks for you.

That’s where JFL Script comes in.

Why JFL Script?

JFL Script gives you the full programming power of JavaScript right inside Jira. While JFL formulas work with common spreadsheet functions such as IF, AND, or DATEDIF, JFL Script gives you the freedom of scripting anything you might need, with full access to all your Jira data, e.g. it lets you:

• Loop through subtask arrays
• Inspect linked work items and dependency relations on child work items
• Calculate aggregated risk signals across parent-child hierarchies

Step 1: The Goal

We wanted a single column on our parent stories that automatically checks all child work items and alerts us if:

1. Any work item is actively blocked by a linked dependency.
2. An incomplete child work item with a dependency risk is within 3 days of the parent work item's due date.

Step 2: The JFL Script Code

Add a Formula column to your JXL sheet, open the editor, and switch the language toggle at the top right from JFL to JFL Script.

Here is the exact script we used:

// Don't display anything for the Objective work type
if (this.workType.name === "Objective") {
  return "N/A - Objective";
}

// Retrieve child work items
const childWorkItems = this.hierarchy.children;
if (childWorkItems.length === 0) {
  return "No child work items";
}

let totalChildWorkItems = childWorkItems.length;
let blockedChildWorkItems = 0;
let openChildWorkItems = 0;

// Loop through child work items to evaluate status and flags
for (const childWorkItem of childWorkItems) {
  const statusName = childWorkItem.status.name;
  const statusCategory = childWorkItem.status.category.name;
  const flagged = childWorkItem.flagged;

  if (statusCategory !== "Done") {
    openChildWorkItems++;

    // Check for blocked status or flagged items
    if (statusName === "Blocked" || flagged === true) {
      blockedChildWorkItems++;
    }
  }
}

// Calculate days remaining until parent due date
const daysUntilDue = this.dueDate ? DATEDIF(NOW(), this.dueDate, "D") : null;

// Return priority signals

if (blockedChildWorkItems > 0) {
  return `🚨 CRITICAL: ${blockedChildWorkItems} Subtask(s) Blocked`;
}

if (openChildWorkItems > 0 && daysUntilDue !== null && daysUntilDue <= 3) {
  return `⚠️ HIGH RISK: ${openChildWorkItems}/${totalChildWorkItems} Subtasks Open (Due in ≤3 Days)`;
}

return openChildWorkItems === 0 ? "Complete" : "On Track";

Step 3: Bringing It Into Our Standups

With our JFL Script formula checking subtasks and other child work items behind the scenes, we could bring that context directly into the parent row and spend less time digging through individual work items during standup.

• Less manual checking: We no longer had to click into parent items one by one to see whether subtasks were progressing or stuck in another team’s queue.
• More relevant results: We could account for different types of work, so items like Objectives automatically return "N/A - Objective" instead of an unnecessary warning.
• Earlier visibility into risk: If a subtask becomes blocked or starts falling behind as a deadline approaches, we can see the warning directly from the parent row.

Series Wrap-Up: From Prioritization to a More Complete View of Work

We started with a simple question: What should we work on first? From there, we gradually added more context to help our team answer that question directly in Jira.

• Part 1: We used basic formulas with functions like IF() and NOW() to flag work that needed attention.
• Part 2: We combined multiple signals to surface bottlenecks, stalled work, and missing data.
• Part 3: We used JFL Script to look across related work and bring subtask progress and blockers into the parent view.

The data we needed was already in Jira. JXL gave us more flexibility to bring those signals together and turn them into something our team could actually use during planning and standups.

What information do you wish you could surface across related Jira work? Share your use case in the comments—we might tackle it next.