Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Dates, Automation, and Jira Product Discovery

For those who are diving into using Jira Product Discovery, date fields there operate a little differently than elsewhere in Jira. Most notably, you can expand your dates to cover entire months, or even calendar quarters. For most Jira Product Discovery use cases, having a fuzzy date range instead of a single date can be very useful for planning. However, the structure of the date field in Jira Product Discovery deviates from how standard Jira works, and can cause confusion with automation rules.

Jira Product Discovery date fields can store dates in three different levels: a single date, a month, or a calendar quarter. As a result of this flexibility, date fields in Jira Product Discovery store two values, a start date and an end date.

Screenshot 2025-12-15 at 11.43.41 PM.pngScreenshot 2025-12-15 at 11.43.50 PM.pngScreenshot 2025-12-15 at 11.44.01 PM.png

Here’s how that impacts those three date options:

  1. A single date - The start and end dates are the same.
  2. A month - The start date is the first of that month, while the end date is the last of that month.
  3. A calendar quarter - The start date is the first of the quarter, while the end date is the last of the quarter.

This poses a bit of a challenge for automation. Because the date fields hold two values, we need to work with that when reading, and populating these date fields. Thankfully, Atlassian is storing this data as a text representation of a standard JSON object, with a predictable structure. That structure is as follows:

{"start":"2025-12-15","end":"2025-12-15"}

In addition to this standard structure, we need to understand the date format in use: Atlassian is using the standard ISO 8601 date format.

With all of this information, we can now start working towards building blocks for use in automation rules.

 


Reading Values via Automation

When you attempt to pull information out of a Jira Product Discovery date field, you will be given a string. So, in order to pull information out, we will need to manipulate the string in a few different ways.

There are two ways you can pull the start and end dates out of the Jira Product Discovery date field.

Option one is converting the text representation of the JSON object into a true JSON object using the jsonStringToObject() method Atlassian provides.

For the start date, you can use this:

{{jsonStringToObject(issue.customfield_12345).start.toDate}}

And for the end date, use this instead:

{{jsonStringToObject(issue.customfield_12345).end.toDate}}

This specific operation will output a true date object that you can manipulate with date math operations, which I talk about later.

 

The second option is using the substring method to split the string at the points we know the date will be in, and then subsequently convert this to a date object for further manipulation. Because the Jira Product Discovery date field uses a standard format, we know at what positions the start date and end date are stored at.

  • Start Date: positions 10 through 20
  • End Date: positions 29 through 39

Here's the specific input for capturing the Start Date from a given date field:

{{issue.customfield_12345.substring(10,20)}}

And for the End Date, we'll use the following:

{{issue.customfield_12345.substring(29,39)}}

For both of those, be sure to use the correct custom field ID!

Importantly, this will pull the date out as another string. Right now, that doesn't make much of a difference, but it's important for later.

 

The easiest way to pull this value out, and store for future use within Jira Automation, is through the "Create variable" action. This action lets us create a new Smart Value / Variable in our automation execution, and populate it with the details of another smart value.

Screenshot 2025-12-15 at 11.57.00 PM.png

You can name the variable whatever you desire, it's the smart value field we need to focus on. You can choose whatever method described above to pull the date out. For later on, it's important to note if you store this as a date object, or a plain string.

 

 

Ok great, now we have the date values in our own variables. If you captured this as a string via the substring method, the date is actually a string of text. So, if we want to manipulate this, we'll need to use another great method: the "toDate" method. This method will modify an existing string and transform it into a date.

While you are able to simply type .toDate within the bounds of a Smart Value, it's best practice to inform the method of the date format being used, so it converts it correctly. You can do that like this:

{{originalStartDate.toDate(yyyy-MM-dd)}}

Having a date in this format lets us do date math against it, such as the very useful method of adding time to a date. Here are some examples:

{{originalStartDate.toDate(yyyy-MM-dd).plusDays(14)}}
{{originalStartDate.toDate(yyyy-MM-dd).plusBusinessDays(30)}}
{{originalStartDate.toDate(yyyy-MM-dd).plusMonths(12)}}

 


Writing Values via Automation

Once we have our dates read and manipulated, we need to re-format them into the expected JSON object format Jira is expecting. As a reminder, this is:

{"start":"2025-12-15","end":"2025-12-15"}

In addition, Jira Product Discovery date fields are not normally available as part of the standard fields listed in the "Edit work item fields" action, so we'll need to get a little advanced.

In the "Edit work item" action, there is an option for "More options". Expanding this menu lets you insert your own JSON to modify the fields on a given work item. This is where we need to get creative.

Screenshot 2025-12-16 at 12.14.49 AM.png

Here's the structure of the data we need to put in this field:

{
"fields": {
"customfield_54321": "{\"start\":\"yyyy-MM-dd\",\"end\":\"yyyy-MM-dd\"}"
}
}

Essentially, we're modifying a specific custom field, and giving it the JSON value it's expecting. Inside that are the two dates we need to provide.

What's great is this field supports Smart Values. So, all we need to do is input the variables you've created at the start into the field, and you're done.

If you're using variables called {{startDate}} and {{endDate}} this is what that might look like:

{
"fields": {
"customfield_54321": "{\"start\":\"{{startDate}}\",\"end\":\"{{endDate}}\"}"
}
}

As usual, make sure your custom field ID is correct!

Depending on if you've done any date math, you may need to use the .toString method to convert a date object into a string. Do some quick testing to ensure your use case is working properly, and you're off to the races!

 

Feel free to sound off in the comments with some use cases for automatically modifying dates in Jira Product Discovery!

Robert

EDIT History:

  • Added additional details for pulling date values out of the Jira Product Discovery Date field using the jsonStringToObject() method, info provided by Bill Sheboy

3 comments

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
December 16, 2025

Hi @Robert DaSilva 

Thanks for your article, and...

As the JPD data format is a text representation of JSON, it can be converted using the jsonStringToObject() function in an automation rule rather than with substrings:

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-text-fields/#jsonStringToObject--

For example:

{{jsonStringToObject(issue.customfield_12345).start.toDate}}

And, I notice some of your expressions use curly / slanted quotation marks ( ” )  rather than vertical ones ( " ), which could lead to problems in smart value expressions.

 

Kind regards,
Bill

Like # people like this
Robert DaSilva
Community Champion
December 16, 2025

Thanks for the feedback, @Bill Sheboy ! I've updated the article to reflect your corrections. I appreciate the collaboration!

Like # people like this
Jared Schmitt
Contributor
December 16, 2025

Thank you @Robert DaSilva for the well-written guide. 

The only question that remains for me is: Why does not every date picker in Jira/Confluence behave that way? Non-JPD folks would like this level of flexibility as well.

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events