Automation - Value increase of Work Item when Due Date changed

[Dariusz Chlebicki]

I’m trying to create an automation in Jira Work Management (Spaces, not projects) where:

• Each Task or Sub-task has a custom number field called Change count.

• Every time the Due Date changes, Change count should increment by 1.

• Initially, the field may be empty (no default value can be set in Work Management).

What I tried:

1. Single automation rule: Trigger on Due Date change → Edit issue → Change count = {{#=}}{{issue.Change count|0}} + 1{{/}}

   • Only increments once, from empty to 1. Subsequent changes do not increment.

2. Using a middleman field and chained automation:

   • Not supported; automation-triggered field updates do not reliably trigger other rules in Work Management.

3. Built-in “Increment” action on the number field:

   • Intended to handle empty fields and increment directly, but in my setup it does not reliably increment beyond 1.

4. Lookup issue / Re-fetch issue data: Not available in Work Management spaces.

5. Setting default value for the custom field: Not supported in Work Management.

Problem:

• Automation increments only once.

• Smart value math seems to fail on empty fields due to caching / context limitations.

• Standard workarounds like chaining rules or fetching issue data are not available in Work Management Spaces.

Goal:

• Reliable increment of Change count every time Due Date changes.

• Preferably without external apps or integrations.

Question:

• Is there a fully supported way in Jira Work Management (Spaces) to reliably increment a number field each time a field changes?

• Are there any known workarounds for the limitation that automation edits don’t re-trigger rules or smart value caching issues?

[Trudy Claspill · Accepted solution]

Hello @Dariusz Chlebicki 

Welcome to the Atlassian community.

Your option #1 works fine for me, incrementing my customer number field with each change to Due date.

Can you show us screen images that show that rule in its entirety and the details of each step?

Can you show us the details from the rule execution audit log showing that the rule was triggered multiple times and the details logged within each execution?

[Trudy Claspill]

[Trudy Claspill]

Thank you for sharing the screen images. I see the likely cause of your issue.

The field that you are setting (1) is not the same field you are looking at in your smart value (2).

This automation does not change the value of the "Change count" field. It changes the value of the "No. of date change" field. Since "Change count" is not changing, that field remains empty (or null if it is not referencing an actual field) and the calculation will return the value "1" every time. So the "No. of date change" field gets set to 1 over and over again.

[Bill Sheboy · Accepted solution]

Hi @Dariusz Chlebicki 

Yes, and...to the suggestions from @Trudy Claspill 

You do not show your entire rule and audit log for context, but from what you show, I hypothesize you have the incorrect smart value for your custom field.  When an unknown smart value is used, that returns as null, and thus your count would always be 1 after updates.

To find the correct smart value or custom field ID for your field, please use this how-to article from Atlassian, or try finding the correct one using the { } smart value lookup at the right side of your field when editing it.

Kind regards,
Bill

[Dariusz Chlebicki]

@Trudy Claspill @Bill Sheboy You both deserve a beer. 

I spend 3h with ChatGPT trying to solve that case.

Indeed I have incorrect name of the smart value but I was tried so many time with new filed that I forgot to change at the end. Anyway if I put "correct" name of smart value - same as my custom field it doesn't work, but well spotted @Trudy Claspill 

With Bill suggestion I tried to find it in lookup and it has completely not expected name as variable like: issue.customfield_11160

It work exactly as you described guys - AI is far behind you. Thanks. 

[Bill Sheboy]

Awesome; I am glad we were able to help!

Regarding the use of AI word-guessing tools for automation rule help, I recommend caution as such tools are missing your specific context...

Such tools generally cannot access your Jira product, site, space, workflow, etc. configurations.  (I hypothesize not even the one from Atlassian can do so.)  Thus, such guessers are at a loss for which of the several possible debugging approaches might help.  One would need to construct a very long prompt listing all configuration information, and even then the parser may have difficulty due to the ever-changing UX  and terminology of Atlassian features over time. (e.g., issue -> work item, project -> space...sometimes, etc. except in Cloud versus Data Center, or on Tuesdays when it is raining :^)

When using such tools, I recommend pausing to understand what they suggest, testing thoroughly in a space / project away from your production data first.

[Dariusz Chlebicki]

Thanks for quick response. I tried exactly that. 

I move fetch action before and after edit work items. It use to work when it's first date change only, so when it's 0, I change a date at it increment to 1. Then none of followed date change increment it further. I don't have in logs full visability in what exactly has been logged. It's only information that work item has been edited sucessfully.