Update Jira Product Discovery date range to be more specific as date gets closer

@Bill Sheboy, that's exactly what I had in mind! 

Thus, if you can determine when to make the change with your rule trigger / work item relative to {{now}} the values could be adjusted as needed.

It's just this part that I can't seem to figure out. That, and writing out the JSON to include all of the possible display options for a given date! 

@jkoch -- You may start with the date / time diff() function with months units, and use some way to detect when the field needs updates.  (e.g., the Due Date changes, time passes, etc.)

But first, something I note in the images for the custom field: it is automatically calculated based upon other data.  That needs to be removed as an automation rule would set the value instead.

Let's add some assumptions and approach ideas.  I think you will need one or two rules based upon:

• WHEN the Due Date field changes THEN update the JPD displayed custom field relative to {{now}}
• EVERY n-time units (e.g., monthly) THEN update the JPD displayed custom field relative to {{now}}
• for the THEN parts...
  • use {{issue.duedate.diff(now).months}} in condition steps or conditional expressions to decide which format to use, and format it accordingly...

As an example, the single-date value would be this, using the jiraDate format on the Due Date:

"{\"start\":\"{{issue.duedate.jiraDate}}\",\"end\":\"{{issue.duedate.jiraDate}}\"}"

The month-date value would add the startOfMonth and endOfMonth functions:

"{\"start\":\"{{issue.duedate.startOfMonth.jiraDate}}\",\"end\":\"{{issue.duedate.endOfMonth.jiraDate}}\"}"

The quarterly / multiple-month range is more challenging, and depends upon how your team defines quarterly alignment.  For calendar-aligned quarters, you could use the format() function with {{issue.duedate.format("q")}} and then use various means to get the JPD date expression: conditional logic expression, lookup table, variables, etc., which will take several steps. Such as:

• create a variable for the starting month number, naming that varStartMonth 

{{#=}}({{issue.duedate.format("q")}} - 1) * 3 + 1{{/}}

• create a variable for the ending month number, naming that varEndMonth 

{{#=}}{{varStartMonth}} + 2{{/}}

• use those to get the dates for start / end of the quarterly range

{{issue.duedate.withMonth(varStartMonth.asNumber).startOfMonth.jiraDate}}

{{issue.duedate.withMonth(varEndMonth.asNumber).endOfMonth.jiraDate}}

• add them to the JSON text for the date

Theoretically, that can all be combined into one expression, although it will be harder to debug / maintain.

I recommend trying the various methods and if you run into challenges, please post here so the community can help.

@Bill Sheboy

I was able to set up an automation to get the date copied over from Jira Cloud to Jira Product Discovery as intended. I didn't see your response until this morning, but I really like the Q formatting (i.e., ({{issue.duedate.format("q")}). I didn't know that was an option, but it's more elegant than my current setup. I like the way you suggested to parse out Q start and end as well. I'll give that a try. Thank you!

And as you mentioned, I still need to create another rule to get Jira to check the date and update the range as the date approaches, but I'm happy I got the first half working. 

Here's the updated automation as of now:

The first few items here are just recording values to the audit log so I have a good reference point for the data directly in the log. 

In the above screenshot, you can see the first variable: {{productDaysUntilPreview}}, which uses the following smart value:

{{today().diff(issue.customfield_12350).days()}} 

Then I created the rest of the variables that I will need later in the flow.  

{{productPreviewMonth}} returns the numerical month for the date (e.g., January =1)

{{issue.customfield_12350.monthOfYear()}}

{{productPreviewMonthStart}} and {{productPreviewMonthEnd}} give me the start and end dates for the given month.

{{issue.customfield_12350.startOfMonth()}}

{{issue.customfield_12350.endOfMonth()}}

{{productPreviewDate}} is just the specific date as a JSON object.

{{issue.customfield_12350}}

Here's how I handled the quarter start and end dates before seeing your reply:

I won't paste every single smart value, but here's Q1:

{{productPreviewFirstQStart}}

{{issue.customfield_12350.startOfMonth.withMonth(1)}}

{{productPreviewFirstQEnd}}

{{issue.customfield_12350.endOfMonth.withMonth(3)}}

These variables give me the right quarter start and end dates for the year of the given date. 

Now that all my variables are created, I can get into my IF conditional path. 

Starting with the largest range, I check if  {productDaysUntilPreview}} is >90 AND {{productPreviewMonth}}  is <4 (i.e., Q1)

If that passes, I edit the JPD target date field accordingly:

{
"fields": {
"customfield_12856":"{\"start\":\"{{productPreviewFirstQStart}}\",\"end\":\"{{productPreviewFirstQEnd}}\"}"
}
}

Q2–4 follow the same pattern:

Q2:

Q3:

Q4: 

Now that we've covered all the possible Qs, we check if {productDaysUntilPreview}}  is >30. If so, we want to update the target JPD field to display the month. 

{
"fields": {
"customfield_12856":"{\"start\":\"{{productPreviewMonthStart}}\",\"end\":\"{{productPreviewMonthEnd}}\"}"
}
}

Finally, if {productDaysUntilPreview}} is <31, we can update the target JPD field to display the specific date. 

{
"fields": {
"customfield_12856":"{\"start\":\"{{productPreviewDate}}\",\"end\":\"{{productPreviewDate}}\"}"
}
}

I'm open to suggestions to simplify or improve the flow! I'm somewhat new to Jira automations, so there is a lot I don't know. Thank you again for your thorough reply and suggestions! 

Edit: Fixed variables in the final IF/ELSE path

@jkoch -- Well done!  Experimentation is a key to success for automation rules :^)

Three things I noticed in your smart value expressions...

#1) If the function today() works, that is likely an undocumented feature...and I recommend not using it.  Instead, please use now: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/#Current-date-and-time---now--

#2) When you do something like this for productPreviewFirstQEnd:

{{issue.customfield_12350.endOfMonth.withMonth(3)}}

Selecting the endOfMonth before the withMonth(3) may cause a problem when the current month and March (i.e., withMonth(3)) have a different number of total days.  Instead, please use withMonth(3) before the endOfMonth function:

{{issue.customfield_12350.withMonth(3).endOfMonth}}

#3) Smart values are name, spacing, and case-sensitive...and, as rule writers we can accidentally pick variable names which collide with built-in smart values...now, and in the future.  Thus, I recommend adding a prefix to variable names to reduce the chance of collisions.  For example, varProductReviewFirstQEnd.

@Bill Sheboy  thank you for all the feedback! 

#1) If the function today() works, that is likely an undocumented feature...and I recommend not using it.  Instead, please use now

Thank you for the recommendation! For that one, I copied it directly from the datetime formatting options in the Smart Values picker, but now I see that now() is the option right above what I chose. 

I swapped today() to now() just to be safe. 

{{now().diff(issue.customfield_12350).days()}}
 

#2) When you do something like this for productPreviewFirstQEnd:

{{issue.customfield_12350.endOfMonth.withMonth(3)}}

Selecting the endOfMonth before the withMonth(3) may cause a problem when the current month and March (i.e., withMonth(3)) have a different number of total days.  Instead, please use withMonth(3) before the endOfMonth function:

{{issue.customfield_12350.withMonth(3).endOfMonth}}

THANK YOU! I couldn't figure out why the last day of March was returning 2026-03-30 in one of my tests yesterday, and I'm sure this is the reason.

I didn't realize you could swap the order of the functions, so this is great. (Like I said, I'm very new to Jira automations!) Fixed!

#3) Smart values are name, spacing, and case-sensitive...and, as rule writers we can accidentally pick variable names which collide with built-in smart values...now, and in the future.  Thus, I recommend adding a prefix to variable names to reduce the chance of collisions.  For example, varProductReviewFirstQEnd.

Good tip! I'll go back through my variables and update to future proof them a bit more. 

Thank you again for all of your help and advice! I'll report back once I get the next part going. 

Sounds good, and...FYI for the built-in smart value information from the { } icon at the right-side of the fields:

My understanding is part of that info is static (i.e., human-written or "borrowed" from other tool docs) and part might be automagically generated based upon the project / space context.  I am guessing the today() reference came from someone typing it in based on using other tools / languages.  Testing shows:

• {{now}} returns the date / time value for "now" in UTC+00:00
• {{today}} returns the date value only, probably in UTC; it automagically converts to a date / time when used inline in smart value expressions

When uncertain about a smart value or custom field ID which rules can access I recommend using this how-to article.  The basic steps are:

1. use your Jira URL in a browser tab to call a REST API endpoint with an example work item
2. search on the page for your field, such as with Control-F (Find)
3. note the smart value and custom field ID, and...
4. if they are missing, the field is likely not supported by rules

@Bill Sheboy, amazing! You are a wealth of information. Thanks for sharing!!

Hi @Bill Sheboy, I'm back with an update to my date automations! I have the daily check automation implemented after some trial and error. 

I am using a scheduled daily trigger that uses a JQL search and conditions. I only need this to run on relevant tickets, so I'm hoping the conditions keep this from bogging down the system. (Though, it's at 1:00 a.m., so there should be very little usage at that time regardless.)

Next, I have all the same log actions and smart variables as I use in the initial automation described in the thread above, so I'm not going to go into detail again here. 

Then, I use the same IF/ELSE block to check how close we are to the Preview date and update the JPD date with the appropriate range. This is also exactly the same as the initial automation. 

I'm open to any and all suggestions, questions, etc.! 

Thanks for the rule images, @jkoch 

For the rule trigger, I recommend moving conditions directly to the JQL (when possible) to make the rule more efficient.

And, as this rule runs daily you may want to use an additional condition inside the branches to check when an update is needed.  That is, only perform the edit when necessary.  This will reduce "noise" in the work item histories from changing to the same value repeatedly...and when the rule has no updates to make, it usually does not count toward monthly rule usage.

Finally...after your testing, is the rule working as expected?

Hi @Jens Schumacher - Released_so ! 

I published the view so it's accessible by anyone:

Then I worked with my web dev team to embed the view via iframe on the website.