Jira Cloud has a native calculated field now. It's called a Jira formula field. You create it like any other custom field, it's on all four editions, and it works in company-managed and team-managed spaces (spaces are what Jira used to call projects). We built five of them on our test site this week. Some parts surprised us: it can't read select fields or priority or other formulas, and an empty formula shows up in JQL as a zero.
The suggestion behind it, JRACLOUD-61966, "Calculated custom fields", was opened on 22 April 2015 and closed as Fixed on 3 August 2026, 4,121 days later, with 542 votes. Until then the answer on the Community was an automation rule that wrote a sum into a number field, or an app.
A lot of the questions during the beta were confusion, and they didn't stop at GA. Mikel asked on the ticket the day it closed: "How come a system field like Created is supported but another one like Resolved/Updated is not supported?" Nobody from Atlassian answered him there. The limitations table further down at least gives him a ticket to vote on.
By the end you'll have four formula fields in a company-managed space (one per output type) and one in a team-managed space. The screenshots are from wolfaenpak, our own test site, captured on 24 October 2026 (the account there uses Jira's dark theme, sorry about that).
[!NOTE]
Prerequisites — Jira Cloud on any edition (Atlassian's GA post: "Enabled by default across all Jira Cloud editions (Free, Standard, Premium, Enterprise)"). For a company-managed space you need Jira admin, because the field is created under Settings > Work items > Fields. For a team-managed space, space admin is enough (not sure which kind yours is? The first section of our Done-column tutorial has a quick check). You'll want a couple of number fields and date fields on your work items to calculate from. We used Story point estimate and a number field we added for the test, called Risk factor. Jira Data Center doesn't have this: its version of the request, JRASERVER-61966, was still Gathering Interest with 65 votes when we read it on 24 October 2026.
[[steps]]
- Create the field — Settings > Work items > Fields > Create new field, type Formula.
- Pick the space — one space or All Spaces.
- Write the formula — choose the output, then the fields and functions.
- Confirm the output type — it's locked after this.
- Check the values — on a work item.
- Search and report on it — JQL, list view, dashboards.
- Repeat in a team-managed space — the Formula tile.
Step 1. Create a calculated field in Jira: choose the Formula field type (company-managed space)
Go to Settings (the cog) > Work items > Fields and select Create new field. A panel opens on the right. Open the Field type dropdown and type "formula". You'll get two results. Pick the wrong one and you get an error saying the field can only be used in Jira Product Discovery; two people hit that on the Community this summer.
Pick Formula, under Other fields. Custom formula is Product Discovery's own field type (it does roll-ups and weighted scores) and you can only use it in Product Discovery spaces. You know you picked the right type when a required Space field appears under Description.
Give the field a name. We'll start with the first of our four examples, a risk-weighted estimate called Weighted effort.
Step 2. Pick the space the field belongs to
The Space field offered "All Spaces" or one single space. Atlassian's page says the same: "You can't select more than one individual space." We picked our scratch space, Formula Lab (key FLAB).
If you want the field in three spaces but not the other forty, you'll have to choose between All Spaces and three separate fields. Our field wasn't on any screen when we created it (the REST view of the field said "screensCount":0). You'll see in Step 5 whether it turns up on the work item anyway. Ours did.
Step 3. Write the formula: Jira formula field functions and field references
Under Formula output leave it on Number for now (Step 4 is all about that choice). Then click into the editor. Typing { opens a list of fields you can reference, and typing a letter lists functions with a one-line description of each. The Format tab next to Formula sets how the value displays; Atlassian's page says you can show a duration as days or hours, or a number as a currency. We left it on the default.
Fields go in curly braces by their display name. Our first formula multiplies two number fields:
{Story point estimate} * {Risk factor}
To confirm the formula is valid, look for no red border or error line under the editor, the button still reads Generate formula, and Create is enabled.
Moritz on the Community spent a while on this step during the beta. He tried {issue.customfield_19054} * {issue.customfield_19055}, then double braces, then the bare field IDs. Then he tried the display names, {Probability} * {Consequence}, and still "the fields are always highlighted in red and cannot be saved." The thread never worked out why. If that happens to you, check that each field shows up in the { list.
The other three company-managed fields we built, with the output type each one needs:
Start by (Date) ADD_DATE({Due date}, -5)
Card label (Text) CONCATENATE({Summary}, " (", TEXT({Story point estimate}), " pts)")
Time to due (Duration) DATE_DIFF({Start date}, {Due date})
ADD_DATE counts calendar days. On a work item due Friday 6 November 2026, Start by came out as Sunday 1 November. There's an ADD_WEEKDAY() if you want working days. DATE_DIFF returns seconds, and a Duration output wants seconds. DAY_DIFF returns a plain number of days.
Which fields the formula can read
On our site the { list offered number fields, dates and date-times, short text and URLs. It also had four system fields: Summary, Created, Reporter, Team. These are the ones we typed in by hand and got refused:
{Priority} Formula error: check formula text
{Change risk} refused (single-select custom field)
{Severity} refused (single-select custom field)
{Labels} refused
{Weighted effort} Formula error: check formula text (another formula field)
{Resolved} Formula error: check formula text
{Updated} refused
{Nonexistent field} refused
Esha Gajula from Atlassian wrote on the GA article that "All fields configured for a Jira space (excluding Product Discovery / Service Management) will appear for Formula Fields." That didn't match what we saw. I think the field type matters more than the space: Resolved and Updated are system fields every space has, and they still weren't in the { list.
Created is a date-time and Due date is a plain date, and you can't mix them. DAY_DIFF({Created}, {Due date}) was refused. DATETIME_DIFF({Created}, {Actual end}) was accepted with Create enabled. Both of those are date-times (Actual end is a field we happened to have on the site).
The function names in the editor differ from the docs
Atlassian's supported functions page has 51 functions in four tables (17 number, 11 text, 19 date and time, 4 duration). The editor listed 56 when we typed every letter from A to Z, which is those 51 plus the five the page files under conditional operators. But ten names don't match:
| Support page row | What the editor offers |
|---|---|
| LEN | LENGTH |
| DATEADD | ADD_DATE |
| TEXT_CONTAINS | CONTAINS_TEXT |
| HOURS_DIFF | HOUR_DIFF |
| MINUTES_DIFF | MINUTE_DIFF |
| SECONDS_DIFF | SECOND_DIFF |
| WORKDAY_DIFF | WEEKDAY_DIFF |
| ADD_WORKDAY | ADD_WEEKDAY |
| TO_DURATION | TO_SECONDS |
| DATETIME_FORMAT | FORMAT_DATETIME |
Some of the page's own examples already use the editor's names (the LEN row's example is LENGTH({Summary})), so I'd trust the editor. We only typed the editor's names, so I don't know if the old spellings get rejected too. You won't find NOW() or TODAY() in either list. JRACLOUD-98610 asks for them (8 votes). Until then, a "days until due" field has to count from another date field on the work item.
If the formula has a problem, the button under the editor changes from Generate formula to Fix formula and Create is disabled. Both buttons use Rovo. On an unfinished SUM({Story point estimate}, it suggested SUM({Story point estimate}), which is valid and also pointless (a sum of one field). We couldn't find an Atlassian page that says whether these buttons spend Rovo credits.
Step 4. Confirm the output type, because you can't change it later
Select Create. Jira stops you with a dialog before it creates anything:
After you confirm, the panel closes and the new field is the top row of the Fields list, with type Formula. When we opened it again with Edit field, the formula and the name were editable, but there was no Formula output control at all. In its place was a new Searcher template dropdown set to "Number Formula Searcher."
So if you guessed wrong (say you made a Number when you wanted a Duration), you create a new field and delete the old one. Atlassian's GA post says the lock is there "to ensure JQL and reporting stability". I think that's about search: the output type decides how JQL indexes and compares the value, and Step 6 shows what that does to empty values.
Step 5. Check the values on a work item
We filled ten work items in FLAB over REST, with story points, a risk factor, a due date and a start date, and we left a few inputs empty to see what happens. FLAB-1 had 5 points, risk 1.5, due 20 November and start 2 November:
The formula fields appeared in Details without us adding them to a screen. If they don't on your site, the field's Actions menu in Settings > Work items > Fields has an Add field to screen option.
Two things caught us out in the values:
-
An empty input makes the whole result empty. FLAB-6 had no risk factor, so Weighted effort was empty. It didn't fall back to 0. If you'd rather get a number, wrap the field:
IF(IS_NONE({Risk factor}), 0, {Risk factor})(that's the editor's own example). Sara asked on the GA article how to get SUM to ignore blanks "without including heaps of IF functions"; as far as I can tell, IS_NONE around each field is the way. -
Decimals come back raw over REST. 21 points times 1.8 showed as 37.8 on screen and as
37.800000000000004over the API. If anything downstream reads that number, useROUND().
Then we checked how fast it updates. We changed Risk factor over REST on three work items and polled every half second. The new Weighted effort was there on the first read, 0.74 to 1.31 seconds after the change. In the browser an inline edit from 1.2 to 2 changed the value from 15.6 to 26 in 0.81 seconds, without a reload.
Step 6. Search, sort and chart it: JQL, list view and dashboards
You can use a formula field in JQL by its name or by cf[id] (Weighted effort was cf[12644] on our site). Jira also adds a clause name with a [Formula] suffix. All of these returned the right work items, so you should see the same on your own fields:
"Weighted effort" = 16
"Weighted effort" >= 6 ORDER BY "Weighted effort" DESC
"Weighted effort[Formula]" > 10
"Card label" ~ "Checkout"
"Time to due" > 1000000 ORDER BY "Time to due" DESC
JRACLOUD-99328 says you can't order by a formula, but on 24 October 2026 our ORDER BY came back in the right order, through the API and in the search screen:
Empty formulas are indexed as zero
The two empty rows at the bottom of that screenshot could just be Jira putting blanks last. They aren't. JQL really does treat them as 0, and an empty date as 1 January 1970:
"Weighted effort" = 0 -> FLAB-10, FLAB-6 (both empty)
"Weighted effort" < 5 -> FLAB-10, FLAB-8, FLAB-7, FLAB-6, FLAB-3
"Weighted effort" is EMPTY -> no results
"Start by" < "2026-11-10" ORDER BY "Start by" ASC -> FLAB-7 first (empty, so 1970)
"Start by" = "1970-01-01" -> FLAB-7
"Start by" < startOfMonth(1) -> FLAB-7 only (nothing real starts before 1 November)
"Start by" is EMPTY -> no results
"Time to due" = 0 -> FLAB-8, FLAB-7 (both empty)
"Card label" is EMPTY -> FLAB-10 (text works)
(We ran the < 5 query as cf[12644] < 5; it's the same field.) We ran them again 26 minutes after creating the work items and got the same result, so it wasn't index lag. Text formulas index their empties properly. Number and date formulas don't, and we couldn't find a ticket for it. Until there is a fix, a filter like "everything with low weighted effort" needs a guard on the inputs. Those are ordinary fields and index their empties properly. We didn't run this one ourselves:
"Weighted effort" < 5 AND "Risk factor" is not EMPTY AND "Story point estimate" is not EMPTY
I'd put that guard in any saved filter you share with a team. And give the index a moment after an edit. After the Risk factor changes above, JQL matched the new values after 2.6, 20.6 and 19.0 seconds, while the work item had them within about a second.
Durations turn into seconds on dashboards
The work item and the search screen show Time to due as "2w 4d" or "4d". We added a Filter results gadget to a dashboard with the same fields as columns, and got this:
That's JRACLOUD-99330, "Formula field with 'Duration' formatting displays raw seconds in Dashboard gadgets instead of Days", a bug with 6 votes and "no known workaround". If a dashboard matters more to you than the nice "2w 4d", I'd make it a Number output with DAY_DIFF() instead. The gadget also listed our rows in key order even though the filter ended with ORDER BY "Weighted effort" DESC. And the date formula's format moves around. It was "Nov 01, 2026" in the search screen and "15/Nov/26" in the gadget, while the native Due date column said "Nov 6, 2026" without the leading zero.
Reading the value over REST
If you export or sync data with a script, this is what a formula looks like through the API. We ran this against FLAB-1:
curl -s -u "$JIRA_EMAIL:$JIRA_API_TOKEN" -H 'Accept: application/json' \
"https://wolfaenpak.atlassian.net/rest/api/3/issue/FLAB-1?expand=renderedFields,names,schema"
Trimmed to the four formula fields, with the names and schema sections left out (the schema keys are quoted below):
{
"fields": {
"customfield_12644": 7.5,
"customfield_12647": "2026-11-15",
"customfield_12648": "Checkout redesign (5 pts)",
"customfield_12649": 1555200.0
},
"renderedFields": {
"customfield_12644": null,
"customfield_12647": "15/Nov/26",
"customfield_12648": null,
"customfield_12649": null
}
}
12644 is Weighted effort, 12647 Start by, 12648 Card label and 12649 Time to due. The schema type for the number was com.atlassian.jira.system.formula.fieldtypes:numberformula. The date and text ones end in :dateformula and :textformula. Duration has no type of its own. It's a numberformula in seconds, so your script has to know which number fields are really durations. renderedFields was null for everything except the date. JRACLOUD-99559 reports the same for the search API.
If you were hoping to script the setup, you can only do half of it. A POST /rest/api/3/field with the numberformula type returned 201 and gave us an empty Formula field with no formula. There was no parameter for the formula or the output type, and the context configuration endpoint answered "This API works only with fields provided by Forge apps."
Step 7. Add a formula field in a team-managed space
In a team-managed space it's a space admin job. Open Space settings > Work types, pick a work type (we used Task), and look at the Fields panel on the right. Under Create a field there's a Formula tile. Atlassian's page lists a few other ways in, like Space settings > Fields or Add column (+) in the List view. We used the work type layout.
Drag it into the work type's fields, give it a name and write the formula. Ours was a number called Days to due:
Select Save changes, and you get a dialog that says "Create 1 formula field" and "A formula field's output type can't be changed once created." You'll see a "Work type updated" message when it's done.
Team-managed will save a formula field with no formula in it. We did that by accident on the first save, with no warning, and the value just stayed empty. When we added DAY_DIFF({Start date}, {Due date}) and saved again, the existing work item showed 18 without us editing it. So I'd look at the formula once more before you leave the page.
The team-managed field belongs to that one space. Over REST it shows "scope":{"type":"PROJECT"} and it didn't come back from the field/search endpoint at all, so a script that inventories fields through field/search won't see it.
Jira formula field limitations: select fields, rollups, formulas of formulas, output type
These are the gaps we hit or confirmed, with the ticket to vote on if one matters to you (votes as we read them on 24 October 2026).
| What you can't do yet | What we saw | Ticket |
|---|---|---|
| Read a select list, checkbox or radio custom field | refused (Change risk, Severity) | JRACLOUD-98942, 2 votes |
| Use Priority or Labels | refused (Priority: Formula error: check formula text) | no ticket we could find |
| Roll values up from child work items | the formula "can only run using data within a single work item" | Atlassian says "not yet supported" |
| Reference another formula field | Formula error: check formula text | JRACLOUD-99874, 1 vote |
| Use Resolved or Updated | refused (Resolved: Formula error: check formula text) | JRACLOUD-99209, 0 votes |
| Use time tracking fields | not offered in the { list |
JRACLOUD-99552, 1 vote |
| Use today's date | no NOW() or TODAY() function | JRACLOUD-98610, 8 votes |
| Change the output type | no control on the edit panel | locked by design |
| Show durations in days on a dashboard | raw seconds in Filter results | JRACLOUD-99330, 6 votes |
| Use it as a board's estimation statistic | not tested by us | JRACLOUD-99810, 1 vote |
| Write a formula longer than 255 characters | not tested by us | JRACLOUD-98844, 5 votes |
JRACLOUD-99874 quotes a different message for formula-of-formula, "Formula error: 2 invalid fields", so the wording can vary. The 255-character limit comes from JRACLOUD-98844 and from a customer who said support told them the internal customfield_ IDs count toward it. Atlassian doesn't document it anywhere we could find, so treat it as reported until you hit it yourself.
I'd expect the select-field gap to hurt most. The beta article planned "Priority, Select (including checkboxes), Labels" as inputs for spring 2026. The GA post lists select fields as "not yet supported" and doesn't mention Priority or Labels at all. Julia on the GA article described risk select lists she was converting to numbers with automation: "It would be great if that could be done with a formula instead of automation!"
If your formula won't save
"Formula error: check formula text" under the editor, with a red border and Create greyed out. We got it for every bad reference where we read the message, so go through the formula field by field. Is each one in the { list? Are you mixing a date with a date-time? Is it a select, Priority, Labels, Resolved, Updated or another formula? Are the braces and quotes closed?
"Edit formula to generate number values" or "Edit formula to generate text values" means the formula is fine but returns the wrong type for the output you picked. {Summary} in a Number field gives the first, {Story point estimate} * 2 in a Text field gives the second. Wrap numbers in TEXT() for a text output.
"Example: SUM({field1}, {field2})" under the editor, together with the error, means a function isn't finished yet.
An error that the field can only be used in Jira Product Discovery means Custom formula was picked instead of Formula (see Step 1).
No Formula type in the dropdown usually means the site hasn't got the release yet. During the beta it needed a toggle in Beta features. Since GA, Atlassian says there's "No more admin opt-in via the Beta Features toggle." During the beta Atlassian also said that sites on bundled release tracks get it a few months later. That's a Premium and Enterprise option where an admin takes most Cloud changes as one monthly bundle, set in Atlassian Administration > Apps > Release management > Release tracks.
Division by zero passes the editor's check. {Story point estimate} / 0 and DIV({Story point estimate}, 0) both left Create enabled. We didn't save them, so we don't know what they show on a work item. Guard the divisor with an IF() if it can ever be 0.
When a Jira Cloud calculated field still needs automation or an app
A formula only sees the work item it's on, so an epic that adds up its stories, or a WSJF score built from select lists, is still out of reach. Atlassian's support page puts it as "It can't calculate costs across work items B and C, or any other work item."
For a rollup, the native option is still an automation rule. A Lookup work items action can find the children (Atlassian caps it at 100 results) and {{lookupIssues.Story Points.sum}} adds them up. Then an Edit action writes the total into a number field on the parent. It works, and it's still an automation rule: each trigger, condition or action it runs counts as an automation step, and extra usage gets billed from 3 December 2026. We measured how many steps common rules use if you want to cost it before you build it. Atlassian's FAQ calls the formula field "a new custom field type that doesn't replace or modify any existing fields or automations", so your existing rollup rules keep running. Atlassian also says formula fields can trigger automation rules and be used in them; we didn't test that part.
On Premium and Enterprise, Plans can roll up estimates and dates from children inside a plan. Atlassian started rolling out scenario recalculation for formula fields in Plans in July, and it was still labelled rolling out in late September. Those roll-ups are calculated in the plan, though. Atlassian's page says rolled-up dates aren't saved when you commit changes back to your work items, so don't count on the parent's own field getting the total.
For select-list maths, people use the workaround Julia described. An automation rule turns each option into a number in a separate number field, and the formula reads that. Decide what None maps to as well, because an empty number field empties the formula (Step 5). If a default value has hidden None from that select's dropdown, here's how to bring it back. Before GA, Atlassian's ticket pointed people who wanted calculated fields to apps (sumUp for Jira, Abacus and ScriptRunner, "neither built nor maintained by Atlassian"). We haven't tested whether any of them does rollups or formulas of formulas.
What you have now
[[takeaways]]
- Formula fields in a company-managed space (Settings > Work items > Fields) and a team-managed space (Space settings > Work types), with the output type chosen for good.
- The field and function names the editor accepts, and the fields it refuses.
- JQL that searches and sorts by a formula, plus the guard for empty values.
- What it doesn't cover: rollups, select fields, formulas of formulas and dashboard durations in days, each with its ticket in the table above.
Have you found a formula that does something clever within these limits, or a way around the empty-is-zero search? Tell me in the comments or mail gabriela at leanzero.net, and I'll add the good ones here :)
Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.
Top comments (0)