We are experiencing a critical bug where our automation rules cannot read the value of the system Start Date field when an issue is created. This prevents any date-based conditions or calculations from working.
The Problem:
When an issue is created, any automation rule attempting to use the {{issue.startDate}}
smart value finds it to be empty. This happens even though the "Start Date" field is required on our Create Issue screen and a value is always provided by the user.
Troubleshooting Steps Taken:
We have performed extensive troubleshooting and confirmed the following:
The field is configured correctly: The system "Start Date" field is present and required on the relevant "Create Issue" screen.
Smart Value is empty: We used a debug rule to write the value of {{issue.startDate}}
to a text field. The log consistently shows the value is empty (Raw Start Date: []
).
Re-fetch issue data
does not work: We added the Re-fetch issue data
action to the beginning of the rule. This is the standard solution for timing issues, but it did not solve the problem. The {{issue.startDate}}
value remains empty even after the re-fetch.
All conditions fail: Because the smart value is empty, no automation condition works correctly.
The Issue Fields Condition fails due to a UI bug (the "Save" button disappears when a date smart value is entered).
The JQL Condition fails with a syntax error when comparing to another date field.
The Advanced Compare Condition fails because it doesn't recognize the smart value as a date and doesn't provide the "is before" operator.
Hi @Yuri Suppa
Without seeing the specifics of your rule and audit log details...I hypothesize you are using the Work Item Created trigger (or the multiple event trigger including create).
There is a known racetrack timing defect with work item creation such that the rule can start before all data is available to the rule. This can lead to strange errors or unexpected condition results due to empty fields. In a recent post, an Atlassian automation team member stated they know about the problem and are actively working on architectural changes to solve it; there was no timeline communicated.
The mitigation for this is to always add the Re-fetch Work Item Data action immediately after this trigger type. That will slow the rule a bit and reload the data before the steps proceed. Please add that and retest.
If that does not help, please post the following for more context:
Kind regards,
Bill
One more thing to check: smart values are name, spacing, and case-sensitive. When an incorrect one is used, that returns as null and often fails silently.
I believe the correct one for that field is {{issue.Start date}} and sometimes the custom field ID must be used.
Please see this how-to article to determine the supported smart values for your work item within rules: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for the answers. My rule was actually trying to use the system Start Date field to calculate it against current day and transition to status on a jira software project.
The debugging rule that I am trying (on sandbox), just to see if Start Date is read is the following:
Trigger: multi, item created/item updated
Action: re-fetch
Action: edit custom fields:
- Date Check Value: {{issue.startDate.diff(now.plusBusinessDays(3)).toDays}}
- Debug output: Raw Start Date: [{{issue.startDate}}]
Target Date: [{{now.plusBusinessDays(3)}}]
---
Calculation Result: [{{issue.startDate.diff(now.plusBusinessDays(3)).toDays}}]
The rule is successful, however my field shows an empty value:
Date Check Value
None
Debug Output
Raw Start Date: []
Target Date: [2025-07-24T12:13:45.0+0000]
—
Calculation Result: []
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.