Due date automation based on SLA

[Vladislavs Sakadinecs]

GOAL: Sync the Due date field with the SLA breach time (Time to Resolution / "TTR", customfield_12581) so both show the same date.

FLOW STRUCTURE:
1. Trigger: Field value changed → Status → Value added → All work item operations
2. Action: Re-fetch work item data
4. Action: Edit work item fields → Due date

SMART VALUE TESTED (in both the Log action and Due date field): {{issue.customfield_12581.ongoingCycle.breachTime.jira}}

RESULT:
- Audit log shows all steps "Success"
- The Log action shows the value as empty (just "TEST:" with nothing after it)
- Due date field remains "None" after the flow runs

VERIFICATION VIA REST API:
Fetched https://<domain>.atlassian.net/rest/api/2/issue/OPS-237?expand=names directly, and customfield_12581 clearly contains an active ongoingCycle with a populated breachTime

I've also tried:
- {{issue.customfield_12581.ongoingCycle.breachTime.jira}}
- {{issue["customfield_12581"].ongoingCycle.breachTime.jira}}
- {{issue.TTR.breachTime.jiraDate}} All resolve to empty in the Log action.

What am I doing wrong?

[Joseph Chung Yin]

@Vladislavs Sakadinecs -

It seems your smart value syntax is not correct.  Please take a look at this KB reference - https://support.atlassian.com/jira/kb/how-to-find-smart-value-of-sla-component-of-jsm-issues/

Hope this also helps.

Best, Joseph

[Andrea Robbins]

I would change a few things, I would use the SLA Rest API: https://developer.atlassian.com/cloud/jira/service-desk/rest/api-group-request/#api-rest-servicedeskapi-request-issueidorkey-sla-get - get this info via the send web request.

Use the send web request using the sla endpoint and drill down to the value you're looking for keeping the array in mind.

Your way may work, but I haven't used it before.

[Gabriela - LeanZero]

Hi @Vladislavs Sakadinecs

Your first form is the documented one. Atlassian's KB for this exact failure uses the same customfield_XXXXX.ongoingCycle path and says the custom-field-ID version "can be more direct", so that isn't where your problem is: https://support.atlassian.com/jira/kb/comment-with-sla-smart-value-fails-in-jira-automation-rule/

The other two are malformed. Bracket notation isn't the documented way to index anything in a smart value, that's .get(index), and {{issue.TTR.breachTime.jiraDate}} skips ongoingCycle, uses your own shorthand where the SLA metric name goes, and ends on jiraDate, which isn't a key on breachTime at all. That object only carries iso8601, jira, friendly and epochMillis.

What's biting you is that {{issue}} is a snapshot frozen when the rule triggered, and the SLA cycle gets recalculated after the status event lands. You already have the Re-fetch in there, which is the documented fix, but a single one often loses that race, and the same KB says the value can still come back blank even with a Delay in the rule, which is a Premium and Enterprise action anyway.

That leaves the workarounds Atlassian lists on JSDCLOUD-13935, which they closed as Not a bug: a Send web request purely to burn time, several Re-fetch actions stacked before the value gets read, or a scheduled trigger instead of the status change. Stefan did the same job on an older thread, Time to resolution into Due date, and got there with several re-fetches plus a couple of branches: https://community.atlassian.com/forums/Jira-Service-Management/Time-to-resolution-copy-to-Due-date-minus-one-day/qaq-p/2286780

Log {{issue.customfield_12581}} bare, with no path on it, right after the re-fetch. Your REST check already shows ongoingCycle populated on OPS-237, so the cycle probably hasn't stopped, but the bare log tells you whether the SLA object is in the rule's copy of the issue at all. If it does come back with ongoingCycle=null, the accessor is {{issue.customfield_12581.completedCycles.get(0).breachTime.jira}}, since completedCycles is an array and the get(0) is the bit people leave off.

Keep the .jira ending once you get that far. On Stefan's thread it goes straight into Due date with a minusDays(1) chained onto it.

The KB and JSDCLOUD-13935 are both written for the work item created trigger. That older thread hit the same thing on a field-value-changed trigger, which is the same class as your status change, but I haven't reproduced yours myself.