Automatic reminder when the remaing time before due date and time is 40%, then when 20% and 10%

[Quentin Ceulemans]

Hello Everyone, i'm pretty new to Jira Automation and my rules keeps failing so i'm turning to you.

I want to create automatic email reminder for my team when the remaining time in the field "due date and time" is 40%, then when 20% and 10%.

When those pourcentages are achieved, i want Jira to automatically Send an email to the selected assignee where it would say:

"Hello "selected assignee" 

Here is a quick reminder for the task(s) "selected issue" you have about 40% of the allocated time lef for the task(s) to be completed.

We know you're working on it, it is only a simple reminder to help you prioritize your work.

Thank you."

That would be the message when the remaining time is 40% prior to the issue creation date. I would need to implement another automation with a different message when th time remainign is 20% and finall when it's 10%.

Ideally, each rules would trigger only once per issue, and would adjust if i'm modifying the "due date and time".

If anyone could give me the exact steps (preferrably screenshots) to be able to implement this, it would literally save my soul.

Thank you so much in advance

[Bill Sheboy]

Hi @Quentin Ceulemans 

I am unclear how your team is using these date fields to assess progress.  Perhaps if you clarify the team's practices the community will have more information to make suggestions.

For example...

Often teams forecast the effort to complete a specific work item during intake and / or backlog refinement.  And based on what else the team is doing (work in progress, or WIP) and the team's Capacity to complete work, a completion timeframe may be forecasted.  This is how many agile delivery teams manage work, particularly Scrum teams.

Other times, there are fixed, want dates requested by stakeholders.  And so the team again forecasts the effort, reviews their WIP and Capacity, and assesses if that date is realistic, or if instead a piece / increment of that work could be completed by that want date.

You describe a scenario where on a specific date (using the Start Date issue field), a Due Date is set for work completion.  Is the Start Date the date / time when the work actually begins?  If so, it seems the team is using calendar days (i.e., time-based) as a forecasting tool.  Jira already has a mechanism for time-based estimation; have you considered using that instead?

Later you note the Due Date can change.  Wouldn't that reset your "progress percentage" , lose visibility to the original forecast, and lose history data the team could use to improve their working methods?

Kind regards,
Bill

[Quentin Ceulemans]

Hi @Bill Sheboy 

Thank you for taking the time to consider my request. To clarify our workflow, we are currently operating within a company-managed Kanban board workspace with both internal and external teams. However, only the internal team is currently using Jira.

We primarily rely on fixed deadlines set by our founders, who possess extensive experience in both coding and business. As such, they directly establish deadlines rather than using original time estimates and remaining time.

Regarding the potential loss of data due to due date changes, I acknowledge this as a valid concern. However, we sometimes encounter situations where external dependencies, rather than internal team delays, necessitate deadline modifications. To address this, I guess I could implement an automatic required field that prompts users to provide reasons for due date changes, maintaining a record of these modifications for future reference.

To explain more of the vision, I believe implementing a percentage-based deadline reminder system would be more effective than relying on specific dates. This approach would allow for accurate reminders that consider the task's duration. For instance, marketing tasks may have extended deadlines, and a percentage-based system would account for this.

Instead of triggering reminders based on specific intervals like 15, 5, and 1 day before the due date, I would like a system that calculates the time between the start date and due date. This system would automatically send email reminders when 60%, 80%, and 90% of the time between the start date and due date has elapsed. I recently implemented an automation to automatically apply the start date to the issue creation.

Did that help provide clarity to my question and hopefully get some help in resolving it?

[Bill Sheboy]

Thank you for the additional details, Quentin.

Some things I notice in that information...

Are the founders you note, who are providing the "deadlines", also coding with the team?  If not, I find when people who are not doing the work provide the forecasts, they can be disconnected from the facts on the ground, and misunderstandings occur.

You describe using the percentages, and that may make sense to the founders providing forecasting.  Yet I wonder about a person doing the work: would they find it more valuable to know there are 2 days remaining or 20% remaining?  Perhaps consider how to make both visible for the different audiences. 

• One way would be to calculate the percentage daily (with a scheduled trigger rule), store that in a custom field, and then use a dashboard (or quick filter on the board) to see the issues with the approaching percentage thresholds.
• And then for a time-based reminder for remaining days (or overdue), basic JQL could be used with a different scheduled trigger rule, or again, a quick filter for the board.

Regarding changes to the dates, which then reset people's understanding of progress, consider how to make that visible.  For example, adding the equivalent of an asterisk to the forecast, such as with a label: Due-Date-Changed.

[Quentin Ceulemans]

Hello @Bill Sheboy ,

The founders are also working with the team. The fields "start date" and "due date and time" are both visible within the issue for users to see, making the "remaining%" field purely for indicational and automation purpose.

this is currently the smart value i'm trying to use to calculate the percentage automatically and adjust it every hour in the custome field remaining time, but it is not working. Can you help me make this smart value valid?

{{issueDueDateandtime.minus(NOW())}} / {{datediff.({{issueStartDate}}, {{issueDueDateandtime}}) * 100

Once this automation is up and running, i believe i can create the other automation checking the status of each tasks and sending reminders when 60%,80 and 90% of the time is gone for each.

[Bill Sheboy]

First, several questions about what you are showing.

Is the "Remaining Time" field intended to be a percentage value?  For example, a number such as 50.0

Is the "issueDueDateandtime" a custom field in the issue?  The built-in "Due Date" field is a date field only.

Is "issueStartDate" a custom field in the issue?  The built-in "Start Date" field is a date  field only.

{{now}} normally is not subtracted from other date/time values.  Instead the date/time functions are used to perform the math: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/

Your expression is not a valid smart value, math expression for rules.  Please look here to learn the two syntaxes, inline and long form: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-math-expressions/

I am assuming the following, and we can adjust based on your answers to the above questions:

• The built-in "Start Date" field is set to the current date when an issue begins work
• The built-in "Due Date" field is set to the target completion date when an issue begins work.  And so the forecast is in whole working days.
• When the "Due Date" field is set, it is always after the calendar date of the "Start Date" field
• As the calculations are in whole working days, the rule schedule could be changed to run once per day, such as just after midnight

The total forecast would be: {{issue.Start date.diff(issue.duedate).businessDays}}

The current elapsed time would be: {{issue.Start date.diff(now).businessDays}}

Combining that, and truncating to a whole number, the percentage would be:

{{#=}}ROUND({{issue.Start date.diff(now).businessDays}} / {{issue.Start date.diff(issue.duedate).businessDays}} * 100, 0){{/}}

[Quentin Ceulemans]

Hello @Bill Sheboy 

- Is the "Remaining Time" field intended to be a percentage value? Yes.

- Is the "issueDueDateandtime" a custom field in the issue? Yes it is, it has been created using a date and time picker.

- Is "issueStartDate" a custom field in the issue? Yes it is, it has also been created using a date and time picker.

- The built-in "Start Date" field is set to the current date when an issue begins work

- The built-in "Due Date" field is set to the target completion date when an issue begins work.  And so the forecast is for the whole working day.

- When the "Due Date" field is set, it is always after the calendar date of the "Start Date" field

- As the calculations are in whole working days, the rule schedule could be changed to run once per day, such as just after midnight

All above assumptions are correct. Please take into consideration that the Due date field is not included, as I replaced it with the “Due Date and time” field for more accuracy. The ID for this field is cf[10032] as indicated in the browser.

Thank you for the smart value. So after trying the query, you can see that Based on the picture below, it’s now asking me to run the JQL in order to edit the issue. I have been playing around with Chat gpt to solve the last piece of the puzzle but without success.

[Bill Sheboy]

That error is describing the problem: the rule is trying to edit issues but none were provided.  You would need to decide which issue you want to update, write a JQL statement to find them, and then use that JQL in the trigger.

[Quentin Ceulemans]

Hello @Bill Sheboy 

Thank you so much for your help so far, I'm getting closer.

Now that i entered the issues status i want the automation to edit, it's giving me this error message.

And those were the the other screens.

Please not that the custome field i selected to operate this rule is called "live Remaining Time" and it's a number field in order to be able to show %.

[Bill Sheboy]

That error is indicating the denominator in the expression (after the divide operator) is null...and so perhaps one of the fields is empty or the smart values are incorrect.

Please copy and paste the expression you are using to set the "Live Remaining Time" in a message.  That will help us review the cause.

[Quentin Ceulemans]

Hello @Bill Sheboy 

I see, I am using the smart value you provided me before to set the "live remaining time" in the "edit issue" component. 

{{#=}}ROUND({{issue.Start date.diff(now).businessDays}} / {{issue.Start date.diff(issue.duedate).businessDays}} * 100, 0){{/}}

By "one of the the fields is empty" do you mean that it might not see the "start date" or "due date and time" fields within my issues? Or do you mean other fields?

Maybe i need to allow one extra set of actions in order to make it work?

Thank you,

Quentin

[Bill Sheboy]

Thanks, Quentin.  Based on that information, the value issue.duedate appears to be null.

Let's write some values to the audit log to confirm that using the Log action:

{{issue.key}} has a due date of {{issue.duedate}}; 

I suspect the smart value is different for your instance, as my answer was based on Jira Cloud.  Are you using Jira Cloud, Server, or Data Center?

[Quentin Ceulemans]

Hello @Bill Sheboy 

Thank you again for your help so far.

When adding an extra step to my automation, it has been able to succesfully pull the datas from the issues, but the same unary operator remain. Did i correctly implmeented it within my automation?

I am using Jira cloud server.

Maybe the problem is the custom field "Live remaining time" in itself? I created it using a number field, should it have another specification?

[Bill Sheboy]

If you are using Jira Cloud, that should be the correct smart value but it appears to be empty.

So step one: do those issues have a value in the Due Date field?  If not, that is the problem.

If you instead are using that custom field you mentioned, please let me know exactly which fields your calculation is using.  Then we can update your smart value expression to match those.

FYI: when in doubt if a rule is using the correct smart value (or if it is supported by rules), this how-to article can help.  Essentially you...

1. Identify an example issue with your field
2. Call a REST API function with a web browser
3. Search for your field in the page, such as with CTRL-F
4. If the field is found, it will show the smart value and custom field id that can be used.  If the field is not found, it is not supported by automation rules.

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

[Quentin Ceulemans]

Hello @Bill Sheboy 

Thank you for those updates and sorry for the late reply, was out this week-end.

I am in fact not using the "due date" built in field as i wanted more precision. Instead i'm using "Due Date and time" which is a date and time picker custom field and it's ID is 10032

So to resume so far, for my automation:

Fist i am using a "shceduled" trigger set for everyday at 12.01am

The jql i'm running for it is: status in ("To Do", "Recurring", "In Progress", "In Review")

Then i'm using an "Add value to the audit log" action

the log message is 

{{issue.key}} has a due date of {{issue.duedate}}; 

then final step, i'm using an "eddit issue field" action. I've picked my field called "Live Remaining time" for it and the smart value in it is: {{#=}}ROUND({{issue.Start date.diff(now).businessDays}} / {{issue.Start date.diff(issue.duedate).businessDays}} * 100, 0){{/}}

that is the recap of my automation rule, do you have all the elements to finalise this querry?

And thank you for the additional atlassian info, i will check it out too.

[Bill Sheboy]

As you are using your custom fields, which are date/time type, you may not want to use businessDays with the diff() function.  That would only be whole-days of numbers.

There are no other "business" units for that functions, such as hours, minutes, or seconds.  And so any diff will be in clock time, 24x7, including weekends and non-working hours.  Please decide which units you want to use: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/#Date-difference---

Once that is decided, you can try modifying your rule:

• change to your fields instead of Start Date and Due Date,
• change the units for the diff, and
• then test the results.

[Stephen Wright _Elabor8_]

Hi @Quentin Ceulemans 

How is the percentage being calculated?

A Date Time Picker isn't a time tracking field (like Original Estimate) - it's a set point in time - so there would need to be a starter date to allow for a percentage to be calculated.

Is the start date in another field? Or is it based on created date?

Ste

[Quentin Ceulemans]

Hi @Stephen Wright _Elabor8_ thank you for your fast answer.

Ideally, i would like to not add the "start date" field as the start is when the deadline in the "due date and time" is set, and i have one less box to tick.

does the system automatically "remember" when you're setting the "due date and time ?

Based on that answer, is it possible to set an automation like this?

Thank you

Quentin

[Stephen Wright _Elabor8_]

Hi @Quentin Ceulemans 

So to confirm...

• Start Date/Time is the date you set the Due Date/Time and...
• The Start Date/Time, along with the Due Date/Time, can change during the time inbetween and...

If you do change the Due Date/Time, does this also reset the Start Date/Time? And therefore the % goes back to 100%?

Or does changing the Due Date/Time just extend the time (thus no change in Start?)

Ste

[Quentin Ceulemans]

Hi @Stephen Wright _Elabor8_ 

• Start Date/Time is the date you set the Due Date/Time. That is correct.
• The Start Date/Time, along with the Due Date/Time, can change during the time in between. That is correct.

If i do change the Due Date/Time, i would ideally like that it extend the time remaining, so no change to the start Date/Time.

Thank you again for your time.

Quentin