Replacing Structure's Expr Formula Engine

Foundation MVP doesn't ship a formula engine. If Structure Expr is load-bearing for your team — ROI columns, weighted priority scores, calendar-aware rollups — Foundation isn't a drop-in replacement today. Here's a frank breakdown of what ports to Jira native tooling right now, what needs a workaround, and what genuinely has to wait for the Q1 2027 formula engine.

What does Structure Expr actually give you?

Expr is Structure's embedded formula language — a typed, pure-functional expression language with 100+ built-in functions. It lets you define a column whose value is computed from other columns, issue fields, or aggregates of child rows. A typical Expr column looks like a spreadsheet cell: sum(children.story_points) / count(children), or if(status = "Done", budget - spent, null). The language knows about the hierarchy, so formulas can roll up from leaves to parents, aggregate by level, or reference grandparent fields directly.

The real power isn't any single function — it's the composability. Power users build one formula for “weighted risk score,” another for “effort remaining,” a third that combines the first two into “priority index.” Reports get layered. Dashboards get derived. Over a year or two a team can accumulate dozens of Expr columns that together encode their entire portfolio methodology. This is the main reason to stay on Structure. If Expr is load-bearing for you, Foundation isn't the answer today.

Everything else in Structure has a reasonable Foundation equivalent in 2026: hierarchy, JQL generators, saved views, permissions, Gantt. But the Expr gap is real, and pretending otherwise wastes your time during evaluation. The rest of this guide is a field-by-field look at which Expr use cases have a Jira-native replacement today and which don't.

Which Expr use cases map to Jira automation rules?

Jira automation rules are Jira Cloud's built-in event-triggered rule engine. When an issue changes in a way the rule cares about, the rule runs branches and conditions and updates fields, transitions status, or sends notifications. This covers a meaningful slice of Expr use cases — specifically the ones where your formula is really “when X happens, derive Y and write it to a field.”

Status rollups port cleanly. An Expr formula like if(count(children) = count(children[status = "Done"]), "Done", "In Progress") is a classic parent-Done rollup. In Jira automation you write: when any child issue transitions, check if all children are Done, and if so, transition the parent. The derived “parent status” becomes a real field on the Jira issue, which is actually better than an Expr column for cross-tool visibility.

Conditional field updates port cleanly. “If story points > 13, set priority to High” or “if due date is within 3 days, add label 'at-risk'” — all standard Jira automation patterns. The rule runs on issue change and writes to a real Jira field, so the derived value shows up in Foundation, in native Jira views, in dashboards, and anywhere else that reads Jira.

Time-based alerts port cleanly. “Flag any epic where the due date is past and status is not Done” is a scheduled Jira automation rule with a JQL condition. It doesn't need Expr at all.

The tradeoff: Jira automation runs on events or schedules, not on read. Expr recomputes on every render, so it's always up-to-date without a latency window. Automation writes to fields, which is more durable but also costs a write and some automation quota. For most of what Expr does in the “conditional update” category, the automation pattern is a fair substitute.

Which map to JQL and custom fields?

JQL is Jira's query language — powerful for filtering and counting, weak for arithmetic. JQL can answer “how many open bugs are assigned to this epic,” but it can't do sum(story_points) / headcount. That gap is filled by Jira custom fields — specifically Number fields, Calculated fields, and ScriptRunner (or similar) scripted fields.

Simple sums and counts via JQL counters. Tempo, Appfire, and several other vendors ship “JQL counter” custom fields that run a parameterized query and show the result count on each issue. If your Expr formula is count(children[status = "Blocked"]), a JQL counter field with the query parent = currentIssue() AND status = Blocked gets you there without Expr.

Derived arithmetic via ScriptRunner. For formulas like budget * (1 - percent_complete), a ScriptRunner scripted field reads the two input fields from the issue and publishes the computed value as a read-only Number field. Foundation reads these fields like any other column — a ScriptRunner-computed “remaining budget” field appears in your Lens alongside native Jira fields with no extra configuration.

Cross-project rollups via saved JQL. Many Expr formulas are really “give me the rolled-up count of issues matching X across the hierarchy.” In Foundation, this usually translates to a JQL Insert Sync Agent that pulls matching issues as children of a parent node, plus a standard count column. The hierarchy itself carries the rollup relationship; you don't need a formula language to express it.

Which require Foundation's roadmap formula engine?

Some Expr use cases have no reasonable replacement today. These are the ones where the combination of (a) hierarchy-aware aggregation, (b) arbitrary arithmetic, and (c) column-level compose-ability is load-bearing. Honest list:

• Weighted aggregations across levels. sum(children.story_points * children.priority_weight) / sum(children.priority_weight) — weighted averages that compose multiple child fields. Neither automation nor ScriptRunner gracefully handles the “sum of products” pattern across a hierarchy.
• Calendar-aware burn rate. spent / ((today - start_date) / (end_date - start_date)) — the projection of current burn to end-of-period, factoring in business days. ScriptRunner can do this on a single issue but struggles to roll it up across 500 children.
• Multi-column conditional ROI scores. if(status != "Done", (value - cost) / effort, null), composed with two or three other formulas. The composition depth is what breaks native Jira — each formula becomes a ScriptRunner field, and chains of 3+ scripted fields tend to have recalculation order issues.
• Transform-at-level aggregations. Expr lets you say “sum story points at the Epic level, but count only blocked Stories at the Story level.” Level-aware rollup logic has no native-Jira equivalent.
• Custom ranking functions. rank_dense(issues, desc(priority_weight)) — returns a 1-N rank across the current set. Requires a formula engine that sees the whole set, not just one issue at a time.

These are the use cases that explicitly wait for Q1 2027. If any of them describe more than one or two of your existing Expr columns, Foundation is not a full replacement today.

What's the honest migration decision tree?

The table below covers the common Expr patterns. Use it as a checklist against your own Structure environment to estimate what's portable now.

Count your load-bearing Expr columns. If most fall in the top half of the table, Foundation is a viable switch today — see the 10-minute migration guide for the process. If most fall in the bottom half, the realistic options are: (1) wait for Q1 2027, (2) run both tools in parallel with Structure retained only for formula-heavy reports, or (3) stay on Structure entirely.

What about post-migration read-only Expr exports?

A pragmatic pattern some teams use during the transition period: keep Structure active on a reduced license tier for exactly one workflow — running the Expr-derived reports — and export the results weekly or monthly as CSV. The CSV lands in a shared drive or a Confluence page, and stakeholders read the derived columns there rather than in a live tool.

This isn't elegant, but it works. The benefit is that you stop paying for full Structure access across all your users — only the handful of people who generate those reports need a Structure license. The rest of the team uses Foundation for day-to-day portfolio work, and the weekly CSV fills the formula gap at a fraction of the original Structure cost. For guidance on reducing Structure seats without disrupting the parallel run, see managing Structure licenses during migration.

When Foundation's formula engine ships in Q1 2027, rebuild those reports inside Foundation and drop the last Structure license. The CSV-export interim is usually a few quarters, not a few years.

What's Foundation's roadmap here?

Foundation's formula engine is publicly scheduled for Q1 2027. That's “sometime between January and March 2027, with no guarantee.” We are not going to tighten the date until we are deeper into the build. What we can commit to:

• Core arithmetic and logic. Numbers, strings, booleans, if/else, arithmetic operators, comparison operators, logical operators. Enough to express 80% of real-world Expr formulas on day one.
• Hierarchy-aware aggregations. sum(children.X), count(children), avg(children.X), max/min(descendants.X). The primitives that make hierarchy-level rollups natural.
• Level-aware rollups. sum(children[type = "Story"].points) — filter aggregation by issue type or custom field before summing.
• Cross-column composition. Formulas that reference other formula columns. This is how ROI scores feed priority indices.

What we are not committing to on day one: a 100% syntactic match with Expr. Expr has ten years of surface area and some quirks. The Foundation formula engine will cover the common cases first and expand as real users tell us what they need. If an Expr-equivalent language matters to your buying decision, tell us which formulas are load-bearing and we'll prioritize them.

For the wider migration context, see the Migrate from Structure pillar guide and the Foundation migration product page.

Frequently asked questions

Related guides

• Migrate from Structure to Foundation — pillar guide
• Structure to Foundation — the 10-minute migration
• Managing Structure licenses during migration
• Foundation migration overview

Sources

• Structure documentation (including Expr) — ALM Works
• Jira automation rules — Atlassian support
• Advanced issue search with JQL — Atlassian support
• Structure by Tempo — Atlassian Marketplace listing
• Foundation for Jira — Atlassian Marketplace listing