Hi everyone,
I set a automation rule to compare value between 2 date picker field, if it's less than 3 days, then set another field value to 5, if between 3 and 7 days, set to 4, etc.
Here is the smart value I put in {{issue.Start Date (migrated).daysBetween(issue.Contained Date).abs}}
However, no matter what dates I pick, it all passed first if block (less than 3)
Unable to resolve this even I tried solutions that provided by AI, anyone can help?
Thanks in advanced
Jack
Hi @Jack Yang ,
Replace the smart value with:
{{issue.migrated.diff(issue.Contained Date).days.abs}}
and keep the rest of the automation unchanged.
This worked successfully in my instance. I've attached a screenshot below for reference.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Jack,
The problem is the smart value itself: daysBetween isn't a function in Jira
automation, so the whole expression never resolves to a number. With the left
side of your "less than 3" check blank, that first branch passes every time —
which is exactly what your audit log shows.
There's a single date-difference function, .diff(), and you append the unit,
then .abs:
{{issue.Start Date (migrated).diff(issue.Contained Date).days.abs}}
(order is unit-then-abs — straight from the docs, e.g.
{{now.diff(issue.created).days.abs}})
Two things worth checking while you're in there:
1) Confirm it actually resolves. Add a "Log action" (or write it to a temp
field) containing just that smart value and run the rule once — you should
get a number like 5, not a blank and not the raw {{...}} text. If it comes
back blank, the field reference is the culprit: "Start Date (migrated)"
with
the space and parentheses can be unreliable, so try the customfield_XXXXX
id
instead, or add .toDate("yyyy-MM-dd") before .diff() if that migrated field
is being returned as text rather than a date.
2) Check the branch logic. If those are separate "if" blocks rather than one
If / Else-if chain, more than one can fire. For "<3 → 5, 3–7 → 4, …" put
them
in a single If / Else-if and order them narrowest-first so the ranges don't
overlap.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks @Artem Nek_Votazz for your quick response, it works properly now, thanks again for your help.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Jack Yang
Yes, and...to the suggestions from @Artem Nek_Votazz
When performing date / time differences, please consider your scenario before adding the absolute value (i.e., abs function) at the end. Perhaps it is an entry error when a person enters the values such that the result is a negative number, and so adding the abs function will conceal that problem.
Please note smart values are name, spacing, and case-sensitive, and often do not exactly match the field name shown in the UX. When an unknown smart value is used, that evaluates to null, often failing silently. This is one reason the suggestion to use the custom field ID can help. To confirm you have the correct smart value or custom field ID, please use one of these methods:
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Jack Yang,
Glad the .diff(...).days.abs fix sorted it out.
One alternative worth knowing for next time: if the tiered value is mainly something you want to see and sort/filter by (rather than physically write into a field), you can skip the automation entirely, iff you're open to an app from the Atlassian Marketplace. JXL for Jira is a spreadsheet/table view where a formula column computes the result live, per row, with no rule to debug.
The date gap plus the tiered mapping fit in a single formula column:
if (DATEDIF(this.startDate, this.containedDate, "D") < 3) {
return 5;
}
if (DATEDIF(this.startDate, this.containedDate, "D") <= 7) {
return 4;
}
return 3;
(Field names are illustrative, you pick them from a list, so there's no name/case guesswork.) Because it recalculates on the fly, there's no stale value when a date changes later, and you can sort, filter, and group by the result like any other column.

If you genuinely need the number stored back on the issue, your automation rule is the right tool. The formula route just removes a moving part when the value is for reporting.
Disclosure: I'm on the JXL team.
Best, Paul
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.