(Apologies to my Australian readers, who I understand have quite enough pigs at ground level.)
I keep a mental list of things Atlassian could ship tomorrow that would make me unreasonably giddy. Not roadmap items. Not strategy. And dear God not another AI feature. Just small structural things that would make the daily work better.
Near the top of that list: more dashboard gadgets. That’s it. I know it’s a silly ask; I think most Atlassian Admins have written off dashboards. But that’s the whole wish. Give me a handful of new gadgets and I will write a glowing post about it, because anyone who has built a dashboard for an executive knows exactly how thin that shelf is and how long it’s been thin.
I mention this so you understand the spirit I’m coming at formula fields with. Because Atlassian just shipped something off that list, and it’s potentially bigger than gadgets.
Jira has a new field type. A real one, built by Atlassian, general purpose, available to normal admins for everyday use. And once you go looking at how often that actually happens, the appropriate response turns out to be something closer to astonishment.
Nobody Ships Field Types Anymore
Walk the list of field types a Jira admin can create today and try to find one that’s genuinely new. It’s harder than it sounds, because several of them are wearing a disguise.
- Parent, announced June 2023 and hitting the Bundled release track in February 2024, was a consolidation rather than an invention. Atlassian’s own wording: “replacing the existing Epic link and Parent link fields with the Parent field.” Two old fields became one old field.
- Space picker appears to be the Project picker under a new name, following the projects-to-spaces terminology change in autumn 2025. Careful here — the rename is confirmed, but that this specific field was relabeled rather than newly built is my inference from doc versions and the Data Center field list, not something Atlassian said outright.
- Assets is the closest counterexample. It arrived via the Mindville acquisition in July 2020, went native to Jira Service Management Premium and Enterprise around April 2021, and was renamed from Insight in mid-2022. Genuinely new-ish, but acquired and tier-gated rather than built as a platform field type for everyone.
- Team came out of Advanced Roadmaps and went native when Advanced Roadmaps folded into Jira Software Cloud Premium in May 2020. App-derived, same story.
And then there’s the group that fooled me completely. The current field types page has a heading called “Information display fields” — Time in status, Date of first response, Days since last comment, Participants of a work item. They read as modern. I had to go double check them (never doubt I try my best to research all my posts!) and they are in fact the oldest things on the page. They come from the Jira Charting Plugin, bundled out of the box since roughly the Jira 4.x era, call it 2009 to 2011. Atlassian’s own migration KB still refers to them as [CHART] Date of First Response and [CHART] Time in Status, brackets and all. They look new because somebody regrouped them under a fresh heading and renamed “issue” to “work item.”
Though I should explain, before the JPD comes busting down my door and arrests me for fraud. And to be fair, it might be an obvious objection: I’m talking about “Just Jira” field types, the list a Jira admin can create for a normal space. Jira Product Discovery is its own story with its own field model, and has picked up several types in the same window. Rolling the two together would make the claim mush – but I do see you guys!
So set the bar at “genuinely new, Atlassian-built, general-purpose, available to normal admins” and after that many qualifiers, formula fields are plausibly the first in more than a decade. Set it generously, counting acquisitions and tier-gated additions, and the answer is Assets in 2021 — still five years. I’ll be honest that the weak link is the “nothing in between” part, which rests on my not having found an announcement rather than an exhaustive changelog audit. If you know of one I missed, I’d like to hear it.
Either way: this is not a release-note line item. This is the field layer moving for the first time in most of our careers, and it’s worth actually looking at.
What They Actually Do
So what has me so excited? It’s just a field, right? Well, let’s look at what this enables. A formula field is a read-only field whose value is derived from other fields on the same work item. You never have to set the value, nor have an automation update its value. It also means you can’t have someone clever with a bulk change update it behind your back. In theory, “It just works.”
The mechanics are refreshingly small:
- Four output types — number, text, date, and duration. Numbers can be formatted as plain values, currency, or percentages.
- Roughly 46 functions, grouped into number, text, date/time, and duration categories, plus the logical operators
IF,AND,OR,NOT, andIS_NONE. - Three creation paths — space field settings, adding a new column directly in List view, or from “Edit fields” on a work item itself.
- Rovo will write it for you. Describe the calculation in plain language and “Generate formula” produces it, with a “Fix formula” pass when something doesn’t validate.
That last one matters more than it first looks. The barrier here was never the math — it’s that you’ll build a handful of these a year, which is nowhere near enough to memorize forty-six function signatures. And almost none of it transfers from JQL, which you use every day, because the two libraries barely overlap. So every formula starts cold, looking up argument order. Describing what you want in a sentence and getting something you can check is exactly the right tool for a task you do rarely and verify quickly.
One thing to decide up front: the output type is fixed at creation and can’t be changed afterward. That shouldn’t surprise anyone — it’s been true of field types since custom fields existed. But it costs less here than with a traditional field, and it’s worth understanding why.
Get the type wrong on a normal custom field and you own a data problem: work out whether the values can even be converted, migrate them, verify nothing was lost, then retire the original. Get it wrong on a formula field and you build a new one with the right type and the same formula. Every work item has the correct value immediately, history included, because nothing was ever stored — it’s all derived from the same base fields.
What you do still have to clean up is references. Saved filters, JQL, automation conditions, dashboards, board configs, and List view columns all point at the old field, and none of them repoint themselves. That’s the real cost of guessing wrong, and it’s what the ten seconds before you click Create is buying you.
The Part That Makes Them Infrastructure
Here’s the piece I think got lost in the beta coverage, and it’s the difference between a nice column and something you build on. Formula results are searchable in JQL and readable in automation. That fact alone makes them infinitely more usable – and turns them from a “well, that’s nice to know” into “something I can build a system on.”
To be clear, that wasn’t true at beta, and a lot of what was written back then (that, to be honest, I internalized myself) reflects a much smaller feature. If you formed an opinion in December, four things have changed underneath it: JQL search works, automation can read the values, the team-managed-only constraint is gone, and output is no longer numbers-only. General availability came with the Summer Release, with Atlassian targeting all Jira Cloud customers by the end of August 2026. And to be honest, I’ve already been experimenting with them.
Why that matters: a derived value can now drive a saved filter, a dashboard gadget, a board quick-filter, and an automation condition — without ever being written to a stored field. The number exists everywhere it needs to and lives nowhere.
Which brings me to my favorite thing about this feature, which is what it lets you delete.
Before formula fields, a derived number on a work item meant an automation rule, at best. Trigger on field change, compute the value, write it back to a stored number field. Every one of us has built that rule at some point. And all that assumes you aren’t trying to do anything more complex, at which point you might end up mucking around with Groovy and ScriptRunner. (No offense, Adaptavist – but even you have to admit that it is using a sledgehammer as a flyswatter.)
And it carries a tax you’ve probably stopped noticing:
- It burns automation quota on arithmetic. You’re spending a metered resource to do subtraction.
- It drifts. Someone disables the rule during an incident, or reorders it, and the stored numbers quietly stop matching reality.
- It’s a loop risk. Writing a field is itself a field-change event, which is how a well-intentioned rollup rule becomes a 3 a.m. page.
- Backfilling is manual. A new rule against an existing backlog means a bulk run somebody has to remember to schedule.
- The value is only as fresh as the last successful execution. A rule that failed on Tuesday leaves you reading Tuesday’s number on Friday.
A formula field has none of those properties. Live, always current, no quota, and no rule to maintain, document, or inherit from the admin who left. If you’re sitting on a pile of recalculate-this-number rules, there’s a real cleanup opportunity in your rule list this week, and I’d go looking for it.
Formulas Worth Building This Week
Enough theory. Here’s what I’d actually build. Every one of these I’ve built and watched render on my own instance, which turns out to matter more than it should — I’ll get to why in the next section.
First, the thing that will trip you up before anything else does: formula fields are very strict about types, and you have to know what type each field actually is. In the examples below, {Actual start} and {Actual end} are DateTime fields — a date and a time. Compare that to {Due date}, which is a Date, with no time component at all. You cannot compare a DateTime against a Date directly, which is what DATETIME_TO_DATE is for, and it insists on a timezone because turning an instant into a calendar date is genuinely ambiguous without one. Nine in the evening in New York is already tomorrow in London. And to finish the set, {Story Points} and {Story point estimate} are Numbers, just for something a bit different.
And credit where it’s due, because this is the good kind of strict. A mismatch refuses to validate and tells you so, rather than handing you a plausible-looking number built on a comparison that never made sense. You find out immediately, which is exactly when you want to find out. So without any more delay, let’s look at some things I found to use these for:
- Did it land late?
IF(IS_AFTER(DATETIME_TO_DATE({Actual end},"America/New_York"), {Due date}), "Late", "On time")— output type: Text. Convert the finish timestamp to a calendar date, compare it to the date it was due, say so in English. Useful in a List view somebody outside your team reads. - How late, in days.
DAY_DIFF(DATETIME_TO_DATE({Actual end},"America/New_York"), {Due date})— output type: Number. The numeric sibling of the one above, and the more useful of the two, because a number is something JQL can filter on. “Everything that shipped more than five days past its date” becomes a saved filter rather than a conversation. - How long it actually took.
DATETIME_DIFF({Actual end},{Actual start})— output type: Duration. Cycle time, without the app purchase or the scripted field it used to take on Data Center. Note there’s no timezone here and no conversion at all: both sides are DateTimes, and the elapsed time between two moments is the same number no matter where you’re standing. You only needDATETIME_TO_DATEwhen you’re asking which calendar day something landed on. - Finding the ones that disagree.
{Story point estimate}-{Story Points}— output type: Number. Team-managed and company-managed spaces store story points in different fields, which everybody discovers the first time they try to report across both. Subtract one from the other and anything non-zero is a work item where the two disagree, which is exactly what you want surfaced after a migration.
None of these are clever. Far from it – I scrounged these together from whatever fields I could find hanging around my personal test instance. But that’s rather the point. They’re the small things you’ve been working around for years, and now each one is solved with a config screen and ninety seconds.
The Supported Field List That Doesn’t Exist
Here’s where I have to stop being purely delighted for a minute. I’ve been playing with these fields for a few weeks now, and as I was reading up on them I found a rather significant shortcoming in the documentation. Again, no surprise — half the reason this blog exists is because of such shortcomings.
Here is what I found, though. The “Create a formula field” page tells you — twice — to “view the list of supported fields and functions for formulas,” and links you to a page called “Supported functions for formulas.” Follow it and you get the function library. Forty-odd functions across numbers, text, dates and durations, all admittedly documented properly. The only problem: there is no list of supported fields. Not an incomplete one, not one that’s hard to find. The page the docs send you to for supported fields does not mention fields at all.
But I never let a challenge stop me. As such, I built one. Two instances, an evening, and a great deal of typing things into the builder to see whether it would take them.
What I could reference: my personal instance would take the following fields (and their types): Actual Start and Actual End (Date-time). Created (Date-time). Due Date and Start Date (Date). Story Points and Story point estimate (Number). Summary (Short text).
What I couldn’t: Select fields. Priority. Versions. User pickers and Group pickers. Description. Paragraph fields. URL fields. Votes. Watchers. Original Estimate, Time Spent and Log Work. Updated. Resolved. And formula fields themselves, which I’ll come back to.
Line those up and there is a rule. Two clauses, and everything I tested fits inside them.
One: the field has to be a Short text, Number, Date, or Date-time. Not “anything textual” — a URL field holds a string and still doesn’t work, because URL is its own field type. Paragraph fields are rich text rather than short text, which is why Description is out for the same reason. Select and Priority hold an option object with an ID sitting behind the label, not the label itself. Versions, user and group pickers, votes and watchers hold references or lists rather than plain values.
Two: somebody has to set the value directly. Updated and Resolved are both Date-times. Both pass the first clause. Neither works — because Jira stamps them, you don’t. Resolved has always been the strange one in Jira anyway, since it isn’t really a field you fill in: it appears when you set a Resolution and vanishes when you clear one.
That second clause explains the missing clock as well, which is the part I find genuinely elegant. A formula’s answer has to follow from the fields it names. Let it read anything that changes on its own — the time of day, a stamp Jira applies behind your back — and it stops being predictable. Three absences, one reason.
The practical version, and the bit worth writing on your hand: if you want something available to a formula, it has to live in a plain Short text, Number, Date, or Date-time field. That’s the workaround for everything on the second list. Including time tracking, where the answer is putting the hours into a Number field and giving up on Original Estimate entirely.
There’s one more thing the rule predicts, and I only tested it after writing the rule down. Can a formula read another formula? Clause one says yes — a formula field produces a Number, Text, Date or Duration, which are exactly the four supported types. Clause two says no, because nothing derived qualifies. So I built a formula on {Story point estimate}-{Story Points}, then tried to reference that field from a second formula. The builder wouldn’t take it. Clause two won.
So no chaining. That also means you can’t decompose a hairy formula into more readable pieces, which is a genuine shame given there’s no way to comment one either. But the rule called it before I checked, and that’s the reason I trust the rest of this enough to publish it. (I told you I do my research.)
Usual caveats. Two instances is not an exhaustive sweep, and Atlassian could extend that list next week without telling anyone. But it held everywhere I poked at it, which is more than I can say for the documentation.
Growing Pains
Now the tempering. I wouldn’t be doing my job as “The Jira Guy” if I didn’t hold Atlassian to account. I’ve always held that everything has room to improve, and oh boy does this have some rough spots. Some of them are understandable given how it was designed. Some of them really do feel like missed opportunities and overlooked details. So let’s dig in.
It’s one work item, always. The documentation is plain: “A formula can only run using data within a single work item… It can’t calculate costs across work items B or C.” So the three things people ask for first — subtask estimates rolled up to the parent, linked-issue costs summed onto an epic, a score averaged across a fix version — are out of scope. Set that expectation in the first meeting, because it will be the first question. This one was a disappointment to me personally, since rolling values up was the first thing I intended to try with these — but it’s not to be.
Reporting stops at the item. A formula answers “what is this number on this work item,” not “what’s the distribution across the backlog.” That’s still dashboards, Plans, or an app. I don’t think it would be difficult to set up math operations across work items — things like standard deviation and summation. That is still something I have to export the data and bring into Excel to do. As I’ve told Atlassian directly: if they don’t like that, it’s their product to fix.
There is no “now.” Not one of the twenty-three date and time functions returns the current date or time. Which rules out the entire category of formulas I reached for first: days until due, work item age, anything SLA-shaped. I’ve made my peace with why, as above. I’d still like the clock.
Time tracking is entirely out. Original Estimate, Time Spent, Log Work. Estimate against actual is one of the most-wanted calculated fields in Jira and you cannot build it, which is why every worked example above leans on story points instead. I have to believe this one is a “not yet” and will be added at some point — it’s right there! But maybe there’s a complication I’m not aware of.
Option fields are out, Priority included. No select is available to a formula, custom or system. Priority is the one that stings: it ships on every work item you own, it’s already a ranking, and it’s the first thing anyone reaches for when building a score. This isn’t an edge case that catches people with unusual configurations — it’s the default path, blocked. If you want a weighted score, every input has to be a number you maintain yourself.
You’re learning a second language. JQL and formula syntax share no functions at all. I went through both libraries and the overlap is the boolean operators and nothing else. JQL selects work items and can’t do arithmetic. Formulas do arithmetic and can’t reach past the work item they’re sitting on. That’s defensible design, but the practical effect is that a decade of JQL fluency buys you nothing here. Not a dealbreaker, just a cost nobody mentions when they hand you forty-six functions like it’s generosity.
And honestly? Of everything in this section, the one I’d most like fixed is the smallest. That missing page. The docs already link to it twice by name — somebody just has to write it. It would have turned my evening into a ten-second decision.
How I’d Use Them Well
So Atlassian has handed us a new tool, and the next natural question is: what are the best practices? I’ve managed to settle on four habits, none of them heavy.
Change every input and watch the number move. Ninety seconds after you build a formula, go through each referenced field and confirm the output actually responds as you change it. Cheap insurance, and the fastest way to catch a formula quietly running on fewer inputs than you think it has.
Decide the output type first. The field will warn you there are no take-backsies when you create it. Again, this should be familiar to anyone working with fields, but it’s always worth a second look to make sure you’re as sure as you think you are.
Check the field is available before you design around it. The list above is a starting point, but the authoritative answer is your own builder. Type the field name and see whether it offers it. Thirty seconds, and it saves you designing a calculation around something you can’t reference and promising somebody a number you can’t produce.
Review them like any other custom field. Read-only makes them feel harmless, but they occupy field IDs, land in configurations, appear on screens, and accumulate exactly like everything else — which is to say straight into the three-layer field problem you already have. Rovo lowering the cost of creating one is genuinely great and also worth watching, in the product where field creation was already too easy.
Wrapping Up
I’ve spent a lot of words here on caveats, so let me be clear about where I land: this is a good thing and I want more of it.
Formula fields do something Jira couldn’t do before. They’re live, they cost nothing to maintain, their results work in JQL and automation, and they retire an entire category of automation rule that a lot of us have been quietly babysitting for years. The rough edges are real, but they’re the rough edges of a young feature, not design failures — and the most annoying one is a missing documentation page, which to be clear I’d be shocked to find still missing a week after someone points it out.
Here’s the twenty-minute version. Go to your sandbox or test space and build one. Pick something you’ve faked with an automation rule, and build it properly. Then change each input and watch the number move. Then open your rule list and count how many rules exist purely to compute a number and write it somewhere. That count is your migration backlog, and I suspect it’s larger than you think.
While you’re there, check whether you have the feature at all — rollout depends on the Beta features toggle under System settings and on whether you’re on the Bundled or Continuous release track. And worth saying plainly, since I saw it questioned in the community: this is not a paid-tier feature. Everything in this post was built on a Free instance.
And if you find a field that works and isn’t on my list, or one that doesn’t and should be, tell me. I’d genuinely like that list to be right, since at the moment it’s the only one there is.
And if this is the direction the field layer is going, I’ll say the quiet part: the pace of change has given us a lot to keep up with lately, and not all of it has felt like it was for us. This one does. More like this, please. I’ll even take dashboard gadgets.
Until then, this is Rodney, asking: have you updated your Jira issues work items today?
Enjoyed this one? These posts are free and always will be — but if this saved you a headache or taught you something worth keeping, you can drop a tip in the Ko-fi jar. No paywall, no subscription, no catch. Just a thanks if the writing earned it.
→ Support The Jira Guy on Ko-fi
Discover more from The Jira Guy
Subscribe to get the latest posts sent to your email.
The Jira Guy 