{{issue.value}} sometimes references the original value before the change triggering the automation

[Eric Dyer]

I have a very simple automation that updates custom fields "target start" and "target end" (custom fields 10040/10041) if a task's sprint field changes.

The automation should update these target start/end dates to the start/end date of the sprint.

Most of the time this automation works as expected. However sometimes I notice that instead of updating the start/end dates to the new sprint, it instead updates to the previous sprint before the change.

So if the task originally had Sprint 1 (and has sprint 1's start/end dates), changing to sprint 2 will trigger the automation, but it will use sprint 1's start/end dates resulting in no date change. Then if I change to sprint 3, the automation will trigger again but populate the start/end dates with sprint 2's start/end dates.

I would have expected that the value of {{issue.Sprint}} should be the new sprint value that has been entered (and triggered the automation) not the original sprint value. But this does not seem to be guaranteed (sometimes it is, but sometimes it's not). 

How can I guarantee that issue.X is always the new value of the field?

[Florian Bonniec]

Hi @Eric Dyer 

Have you try to add Re-fetch Issue data action before ?

Regards

[Eric Dyer]

I'll try that & report back once I see this issue pop up again - but is the behavior I'm describing expected?

[Florian Bonniec]

Not sure, the issue could most likely because there is multiple Sprint in the Sprint field and it may take the wrong one.

{{issue.Sprint.last.startDate.jiradate}} maybe

[Eric Dyer]

Not in this case - I am testing with an issue that has never been pushed out of a completed sprint (so no +1 etc in the sprint field)

[Bill Sheboy]

Hi @Eric Dyer -- Welcome to the Atlassian Community!

The Sprint field is a list of values, including the current and all prior values.  And so your JSON expression is trying to use zero-to-many dates in the field update.

And, the changelog smart values often do not work correctly for the Sprint field updates, and so those cannot be used to get just the added value.  The same is true for other list fields, such as Fix Versions.

Assuming your new sprint value has the latest dates to use, you could use these smart values in your JSON expression: 

{{issue.sprint.startDate.max.jiraDate}}

{{issue.sprint.endDate.max.jiraDate}}

And, what do you want to do when an work item has its Sprint field "cleared" or removed from the Sprint: still use the latest value, or something else?

However, if your new sprint is not the latest date, the rule will need to call the REST API endpoint with the Send Web Request action to explicitly get the changelog entries and parse them to find the added Sprint's values.

Kind regards,
Bill

[Eric Dyer]

Thanks for the detail @Bill Sheboy 

The behavior I want is for my custom start/end dates to be updated to the start/end dates of the latest sprint the task has been updated to (not necessarily with the `max` value for date)

I appreciate that sprint can be a list if a task is dragged through multiple sprints. I don't believe this is the case here as I am removing the old sprint value and replacing with another (not finishing and starting new sprints).

Is it possible there is strange async behavior that is causing the automation to not get the latest value of a non-list issue.item? I would assume that issue.item should be the latest value of that item following the change that triggered the automation?

I will also look into the REST API Endpoint option - maybe it will be more robust. I'm still surprised this doesn't "just work" (in the case that the sprint field is a single sprint, not a list of sprints)

[Bill Sheboy]

Per your comment / question:

Is it possible there is strange async behavior that is causing the automation to not get the latest value of a non-list issue.item? I would assume that issue.item should be the latest value of that item following the change that triggered the automation?

Yes, there is both the known defect with the changelog accuracy (as supplied to rules for list fields) and a potential trigger-timing problem.

For quite some time, the most likely racetrack error / latency for Jira Cloud automation seemed to be with the triggers: Issue Created, Issue Linked, and Issue Moved.  However, I just saw this same symptom with the Field Value Changes for a custom labels field (in my own testing and in another community question yesterday).

So...two things to try:

• Add a Re-fetch Issue action after the trigger, and try the smart values suggested by @Florian Bonniec 
  • {{issue.sprint.last.startDate.jiraDate}} and
  • {{issue.sprint.last.endDate.jiraDate}}
• Use the REST API to get the change log entries, filtering by the field and finding the newest one

Definitely experiment to confirm that first one works as needed, and if not, try the REST API.