nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Custom field with duration format and validation

Helmut Priyanka

I’d like to create several customfields where users can enter a duration, for example in minutes, hours, days,

From what I’ve found, Jira only supports this type of input for certain built-in fields available when creating an issue. Is there any way to achieve the same functionality with custom fields?

I’ve tried using Number and Text custom fields, but the problem is that users can enter virtually anything. My requirement is to have four separate custom fields that accept and validate duration values in a similar way to Jira’s built-in time-related fields.

Accepted answers

All comments

Gor Greyan

Hi @Helmut Priyanka

Welcome to the Atlassian Community!

Jira Cloud doesn't currently provide a native Duration custom field type that behaves like the built-in time-tracking fields such as 30m, 2h, 3d.

If you need full duration-field behavior, parsing, validation, calculations, and reporting, I would look at a Marketplace app that provides a dedicated duration custom field.

We are using the Epic Sum Up field, for example.

https://marketplace.atlassian.com/apps/1213091/esu-sum-up-kpi-budget-reporting-project-epic-overview

Eyüp Firat

@Helmut Priyanka whats your exact use case behind this? maybe we could try workaround with an automation

Duc Thang TRAN

Hello @Helmut Priyanka

What is the purpose of this requirement? Is it intended for estimation and planning?

Jira does not provide this functionality natively, but I have implemented the following workaround in the past:

Create a Number field called “Duration”
Add a Select List field for the unit: minutes, hours, or days
Use automation to convert the value into a standard unit

A simpler option, which I usually require users to follow, is to use a single Number field with a description specifying the required unit, such as hours or days.

Personally, I would recommend using one standard unit to keep the data simple and consistent.

Khrystyna_Dzhus_SaaSJet_

Hi @Helmut Priyanka

Just to clarify the use case: what exactly would these duration fields represent?

Do users need to manually enter values such as 1d 23h 12m or 50:30, or are you trying to track how long a work item spends in particular workflow statuses?

If you need users to enter the duration manually, then you would need an editable custom field with duration validation.

If, however, you want to track time spent in specific statuses, apps such as Time in Status by SaaSJet can create read-only custom fields that calculate these values automatically from the work item history. The value isn’t entered or edited by users; it’s calculated based on the selected status and can then be displayed on the work item or board and used in JQL.

So it really depends on what the duration is supposed to represent. Could you share a little more about what users would enter into those four fields and how you plan to use the values afterward?

Disclosure: I’m part of the SaaSJet team.

Helmut Priyanka

In my case, I’m not trying to track time spent in statuses. I need users to manually enter a duration, for example 1h 30m, 45m, or 2d 4h.

The important part is that the field should validate the input as a duration, rather than behave like a free-text field.

I’d also like to be able to use the value later in JQL, for example to find all issues where the duration entered in this custom field is less than 2 hours.

Ideally, I’m looking for something similar to Jira’s built-in time-related fields, but as a custom field that I can create several times for different purposes.

Helmut Priyanka

Thanks for the suggestion. Yes, the main purpose is planning, dashboards, reporting and JQL filtering. We need several separate duration fields where customers enter how long each phase is expected to take.

I understand the Number + Unit workaround, but I’m concerned about maintenance. For each duration I would need multiple fields and automation triggered on create/edit and whenever either value changes. For example, changing 1 day to 1 hour means only the unit changes, but the normalized value must still be recalculated.

With several duration fields this quickly becomes complex. I’d prefer something closer to Jira’s native time fields, with validation and direct JQL support.

Helmut Priyanka

Thanks for the suggestion! I tested Epic Sum Up and its Duration custom field seems to work as I need. I couldn’t find much documentation about JQL support, but from my initial tests it looks like filtering/searching by this field works as well.

Thanks for pointing me toward Marketplace apps. I’ll check what other options are available and use the trials to compare them before choosing the best one.

Helmut Priyanka

Thanks! The main use case is planning, dashboards, reporting and JQL filtering. We need several separate fields where users manually enter how long different phases of a task are expected to take, e.g. 1h 30m or 2d.

Automation could probably work, but with multiple duration fields I’m worried it would require extra helper fields and several rules to keep everything synchronized on create/edit. I’m trying to find something closer to Jira’s native time fields, with validation and easy JQL support.

Emre Karaduman - The Starware

Hi @Helmut Priyanka
You are not missing a setting: Jira Cloud has no duration custom field type. The custom field type list tops out at Number and Short text, and the only fields that understand Jira's 2w 4d 6h 45m format are the built-in time tracking values (Original Estimate / Remaining Estimate / Time Spent). Those are part of a work item's time tracking, not a field type you can create twice — so you cannot have a second one called Vendor Lead Time and a third called Maintenance Window.
Atlassian has two open suggestions for exactly this, both still Gathering Interest: JRACLOUD-94778 (411 votes) and JRACLOUD-67720 (62 votes). Worth a vote, but not a solution for this quarter.
The Number + unit select + automation approach works, but for four durations that is twelve fields and four rules to maintain, and JQL ends up querying the helper field rather than the one people type into.
The Duration Field:

Input uses Jira's own grammar: 2w 4d 6h 45m, any order, case-insensitive, decimals, bare numbers fall back to your instance's default unit. Anything that isn't a duration is rejected instead of saved.
Display follows your Time Tracking configuration (Pretty / Days / Hours, hours-per-day, days-per-week).
JQL per unit, with autocomplete: "Vendor Lead Time.hours" > 8, "Vendor Lead Time.minutes" < 60, ORDER BY "Vendor Lead Time.weeks" DESC.
Create as many as you need, each with its own name — no configuration screen.
Editable on create, on transitions, and inline on the work item view; included in the navigator column and CSV export.

Docs are here: Duration Field. Free to try if you want to compare it against the other options in the thread.

https://marketplace.atlassian.com/apps/1216682/custom-fields-for-jira?hosting=cloud&tab=overview

Disclosure: I’m part of the The Starware team.

Michał Krysiuk - Terano Apps

Hi @Helmut Priyanka,

Short version: Jira Cloud has no duration custom field type you can create — nothing in the field-type list stores a length of time somebody types in. So it's a choice between compromises, and each one fails differently for what you described (four planned phase durations, typed by hand, used in dashboards and JQL):

Number field, one agreed unit — fastest to set up, sorts and sums, and JQL stays exact: "Design Duration" < 2. But there's no validation beyond "is this a number": 1.5 is hours to one person and days to the next, and 1h 30m is rejected outright.
Number + unit select + automation — your maintenance concern is right, and reporting is the sharper problem: dashboards and filters have to query the helper field, not the one people type into, so a filter built on the "obvious" field is silently wrong. Bulk edits and CSV imports also land outside the rules.
Short text — 2d 4h displays exactly as typed, then sorts alphabetically (10h before 2h), can't be aggregated, and JQL drops to substring matching, where ~ "2h" also matches 12h. Your "less than 2 hours" query isn't expressible at all. Built-in validators don't check formats, and validators only run on transitions — inline edits slip past them.
Subtask per phase with native time tracking — the strongest purely native answer: real duration semantics, rolls up to the parent, full native JQL (originalEstimate, workRatio), zero apps. The price is that it's a hierarchy decision — four subtasks per work item, inherited by boards, filters and reports, and "phase 2 under 2h" becomes a subtask query.

If you compare Marketplace options on trials, two things worth testing early: a numeric JQL alias (thresholds need seconds, not text matching) and validation on inline edit, not just on the create screen.

Full disclosure: I work on Time Tracking Fields for Jira at Terano Apps. It registers time as a field type, so you create as many as you need — in your case four Duration fields (one typed value, no worklogs):

Jira's own grammar, 2w 1d 4h 30m in any combination; anything unparseable is rejected rather than saved, and 90m normalises to 1h 30m using that field's hours-per-day setting. Required is a per-field toggle.
Each field publishes DurationSeconds and Duration in JQL — your example is "Design Phase.DurationSeconds" < 7200, and it works the same in saved filters, gadgets, automation conditions and export.
Available on the create screen, inline on the work item, on transition screens and on JSM portal forms.

A value that isn't a duration is rejected on save

The same field queried directly in JQL — the alias resolves like any other indexed field.

JQL aliases and copy-paste examples are here: Search & Reporting — and the listing is Time Tracking Fields for Jira

Happy to go deeper on the JQL side if useful — that's usually where these comparisons get decided.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud