Jira Formula Fields: What Shipped, Where It Stops, and Why You Don’t Have It Yet

Jira has a genuinely new field type — the first in years that Atlassian built itself, for ordinary admins, on every plan. Here is what it calculates, the two things it refuses to, and why the date in the announcement is probably not your date.

A request older than most of your projects

The canonical ask is JRACLOUD-61966, “Calculated custom fields”. Created 22 April 2015. Resolved as Fixed 3 August 2026. 542 votes and 277 watchers along the way. Atlassian’s own update on the ticket calls it “one of the most requested features in Jira’s history”.

Eleven years and three months is worth a moment, because it tells you what kind of event this is. Walk the list of field types a Jira admin can create today and try to find one that is genuinely new — Atlassian-built, general purpose, available without a Marketplace purchase. It is a short walk. Most of what looks new is a rename or a consolidation of something old, and the nearest real counterexample, Assets, arrived through the Mindville acquisition and landed tier-gated inside Jira Service Management.

The field layer moved. That is rare enough to be worth ten minutes.

What a formula field actually is

The value is calculated, not entered. Atlassian describes the behaviour as “Results update automatically whenever a referenced source field is modified.” There is no path to type a value into one, which means no automation rule and no bulk edit can quietly overwrite it — the property that makes a derived number trustworthy in the first place.

Four output types: number, text, date, duration. Currency and percentage are formatting applied to a number, chosen in a separate step.

Three ways to create one: from space field settings, by adding a column in List view, or from Edit fields on a work item. Both team-managed and company-managed spaces are supported. In team-managed you need space admin permission. In company-managed you pick either All spaces or exactly one space — the documentation notes “You can’t select more than one individual space.”

With Rovo enabled you describe the calculation in English and select Generate formula, with Fix formula as the repair pass. That matters more than it looks. The barrier here was never arithmetic — it is that you will build maybe five of these a year, nowhere near enough to memorise fifty signatures, and almost nothing transfers from JQL because the two libraries barely overlap. Every formula starts cold, looking up argument order.

Results are usable “in the List view, on the board, in JQL search, and in automations”, and Atlassian adds that they are “fully supported in JQL, allowing you to use them in dashboards, automations, and saved filters”.

The 51 functions

Counted directly from the rows of Atlassian’s function reference on 20 August 2026, not from a summary:

Plus + – * / ^, the comparisons = != > < >= <=, and the logical set IF, AND, OR, NOT, IS_NONE. Syntax is FUNCTION_NAME(parameters) with field references in curly brackets.

MIN({Project Cost}, 30 * MAX({Day Rate}, 100))

Source: Atlassian, Supported functions for formulas

Two walls, both official

Wall one: a formula sees one work item

A formula can only run using data within a single work item. For example, a formula field on work item A can only calculate the sum of costs already shown on work item A. It can’t calculate costs across work items B and C, or any other work item.

Atlassian repeats it in the release note as a “what’s next” item, and the wording there matters: cross-work-item rollups are “not yet supported”. Not refused — not yet. So this is out, for now:

• total story points of all children under an epic
• sum of costs across linked work items
• count of open subtasks
• anything aggregating across a project, sprint or hierarchy

Wall two: no select fields

This one is easy to miss and will bite fast. Atlassian: “Referencing single and multi-select fields within formula logic is not yet supported.”

Think about what that removes. Any formula keyed off a dropdown — priority tier, risk category, T-shirt size, customer segment, environment — does not work. A large share of the scoring and labelling use cases people imagine for formula fields run straight into this. Text fields and numbers are fine; the dropdowns that hold your taxonomy are not.

What is left is still real: budget minus spend, days between two dates, weighted scores from numeric fields, formatted labels from summary and status, working days until a due date. That is precisely the half of the problem that never needed a Marketplace app.

Four places the official reference contradicts itself

All four verified on 20 August 2026 in Atlassian’s supported-functions page. Three are a function name that disagrees with its own worked example:

And one is simply wrong arithmetic: the TEXT example takes a Number field with a value of -10 and shows the output as 10. The minus sign vanishes.

There is a fifth wrinkle. Atlassian publishes three different lists of what a formula field can output, on three different pages: four types on the team-managed section, five on the company-managed section with date missing and formats folded in, and six on the field types page. The ticket update settles it — four types, with currency and percentage as formatting.

Why you do not have it yet

This is the question that will fill your inbox, and the answer is not “Atlassian is slow”.

The Summer Release blog, published 5 August, says the fifteen features are “rolling out now and will be generally available across Jira Cloud by the end of August 2026”. That sentence is true for sites on the Continuous release track, which take changes as soon as they ship.

It is not your date if your organisation is on Bundled. Release tracks exist on Premium and Enterprise plans, an organisation admin controls them, and the timing rule is exact: “Bundled changes roll out from 22:00 UTC on the second Tuesday of each month.”

Then the seasonal model narrows it further. Under Jira’s seasonal releases, all significant user-visible changes are held for the three seasonal bundles — June, September and December. Monthly bundles outside those windows may carry only small or low-impact changes, or no user-visible change at all. A brand-new field type is not a low-impact change.

Three more reasons the field type can be absent:

• A beta toggle left over from the rollout. Before general availability, formula fields sat behind a switch in Jira system settings, under Beta features. If your site is still in that state, that is where it lives.
• Free plans did not get beta features. During the beta this locked Free sites out entirely. Atlassian’s general availability note says all four editions are now enabled by default, so this should be historical — but it explains why a Free site saw nothing for months.
• Check Release management → App updates in your Atlassian organisation to see what has actually been delivered, rather than guessing.

Where it is not available at all

Jira Service Management customer portals. Atlassian’s list of custom field types supported on the portal names checkbox, date picker, date time picker, label, number, radio button, select list, text, URL and user picker. Formula is not on that list, and it is not on the “can be added but not shown to customers” list either — it is simply absent. A calculated value can live on the agent view; do not plan on showing it to a customer until Atlassian says otherwise.

Your integrations were not warned. I searched the Jira Cloud platform developer changelog for 2026 and found no entry announcing formula fields or a new field schema type. A new field type that is fully supported in JQL and appears in dashboards and saved filters is exactly the sort of thing that reaches exports, reporting jobs and third-party syncs — and the changelog those teams watch does not mention it. If you maintain anything that enumerates field types, test rather than assume.

Where Atlassian already had this. Jira Product Discovery has had formulas for some time, including a roll-up category and a normalised weighted-score category. The calculation engine was never a research problem. It existed inside the same company, in a neighbouring product, while the main Jira request sat open for eleven years.

So can you cancel the app?

The honest answer turns on one question you can settle today. Sort your existing calculated fields into two buckets.

The left column just became free. The right column is what you are actually paying for — and until now most teams could not see the line between them.

The part nobody budgets for

From March 2026 Atlassian enforces 700 fields per space and 150 work types per space. There is no cap on total custom fields across the site, and trashed fields do not count. The consequence is sharper than a warning:

if your space exceeds the 700 field or 150 work type limit, you’ll be prevented from associating additional fields or work types to your space until you reduce your data.

Nothing exempts formula fields from that count. A formula field that replaces a manually maintained number field is free. One added on top of everything you already have is a slot spent, in an environment where field sprawl is already the most common cause of a slow Jira. The same batch of limits also brings 10,000 select-list options per field across all contexts.

Data Center admins: this is not for you

Formula fields are documented only under Jira Cloud administration. I found no Data Center equivalent and no Data Center changelog entry announcing one.

Against the Data Center clock — no new licences since 30 March 2026, last renewals and tier expansions 30 March 2028, end of life 28 March 2029 — the realistic reading is that it is not coming. If you run Data Center, your options are what they were: an automation rule writing into a normal field, a Marketplace app, or an export to a spreadsheet.

What to do this week

1. Find out which release track you are on before you promise anyone a date. Continuous means end of August applies to you. Bundled means 8 September, 22:00 UTC. A missing Formula option is almost certainly your track, not a fault — do not open a support ticket before mid-September.
2. Inventory what already calculates. An app, an automation rule writing into a number field, a spreadsheet somebody maintains by hand. List them.
3. Sort into single-item and everything else. Only the first bucket is a candidate, and select fields count as “everything else” for now.
4. Rebuild one, not all of them. Take the simplest single-item calculation, build it natively, and compare against the old value on twenty real work items before you trust it.
5. Fix the output type before you save. It is locked at creation.
6. Check your field budget. If a space is near 700 fields, clean up before you add.
7. Handle empties with IS_NONE, or the column fills with holes.
8. Warn whoever owns your integrations. A searchable field type that lands in saved filters will reach exports and syncs, and it was never announced in the developer changelog.

What I could not verify

• Whether formula fields count against the 700-field cap. Nothing exempts them and the cap is calculated through field configuration schemes, but Atlassian does not name them in the limits documentation.
• The exact “first in N years” claim. Rodney Nissen’s analysis puts formula fields as plausibly the first genuinely new, Atlassian-built, general-purpose field type in over a decade, with Assets in 2021 as the generous counterexample. His caveat is that this rests on not finding an announcement rather than an exhaustive changelog audit. I repeat the claim with the same caveat.
• The exact GA date. Atlassian’s ticket update is dated 31 July 2026 and the ticket resolved 3 August, while the 5 August blog describes the release as still rolling out through the end of August. Release tracks explain most of that gap, but not all of it.
• Whether formula fields will reach JSM customer portals. They are absent from the supported list rather than explicitly excluded, and that page may simply not be updated yet.
• Whether the docs call the field read-only. They never use the phrase. The behaviour described is what read-only means in practice, but the wording is mine.

Related reading: 4 Queries That Find Deletable Custom Fields · Jira Database Audit: SQL Queries That Find What the UI Hides · Confluence Content Audit: 10 Queries From Atlassian’s Own Documentation