Custom field with duration format and validation

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.

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.

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.

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.

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

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