I’m working on a Product Research Project in Jira where I only use “concept” issue types. I need help with setting up workflow automation rules but I’m having trouble configuring them correctly. Does anyone have experience with this?
Here’s what I’m trying to achieve:
When a new concept gets created, I want the Start Date and End Date fields to automatically populate with: start date = current quarter, end date = following quarter
When someone changes the status of a concept to “research phase”, the Start Date and End Date should update to: start date = current month, end date = current month + 3 months
Hey! I had this exact setup working last month. Create two separate automation rules - one triggers on issue created, the other on status changed. For quarterly dates use {{now.startOfQuarter}} and {{now.startOfQuarter.plusMonths(3)}}. Way simpler than sophialee’s approach. Just set the ‘when’ condition to only fire for concept issue types or you’ll break other workflows.
Both solutions work, but they’re pretty limited to just Jira. You’ll hit walls when you need complex logic or want to connect with other tools.
I’ve built similar project tracking setups - native Jira automation gets messy fast. Especially with conditional date calculations or syncing data across platforms.
Latenode worked way better for me. Set up triggers that watch for new concepts or status changes in Jira, then run whatever date calculations you need with proper error handling.
The flexibility is huge. Adjust dates for holidays? Easy. Slack notifications when research phases start? Done. Create calendar events or update spreadsheets? All possible.
Debugging is actually manageable compared to figuring out why Jira smart values broke.
Connect it directly to your Jira instance - you’ll be running in 30 minutes. Way more reliable than hoping Jira’s automation survives updates.
I’ve done something similar for research workflows recently. The main problem is that quarterly calculations are a pain with Jira’s smart values - quarters don’t line up with standard date functions. For quarterly automation, I used conditional logic based on the current month to figure out which quarter we’re in. Something like {{#if(now.monthValue <= 3)}}{{now.withMonth(1).withDayOfMonth(1)}}{{/}} for Q1, then similar blocks for the other quarters. It’s more code but it actually works. Monthly calculations are way easier - just use {{now.withDayOfMonth(1)}} and {{now.withDayOfMonth(1).plusMonths(3)}}. One thing nobody mentioned: check your field configuration. Make sure your Start Date and End Date fields are available on the right screens and transitions, or the automation will fail silently. I wasted hours debugging before I realized the fields weren’t even accessible during that workflow step.
That date automation setup should work, but timezone issues will bite you. I’ve seen concept creation dates get offset by hours based on when users log stuff. I added a condition to check issue type first before any date manipulation - saves headaches later. For quarterly logic, skip the complex conditionals. Use {{now.startOfQuarter.format('yyyy-MM-dd')}} for start date and {{now.startOfQuarter.plusMonths(3).minusDays(1).format('yyyy-MM-dd')}} for quarter end. The formatting matters because Jira’s picky about date formats. Test edge cases like concepts created on the last day of a quarter - date calculations get weird sometimes. I’d start with monthly automation since it’s simpler, then move to quarterly once you’ve got the basic workflow nailed down.
I’ve faced similar challenges with date automation in Jira. Using smart values can simplify this significantly. For setting quarterly dates, you can begin with {{now.withDayOfMonth(1).withMonth(1)}} to get the start of the current quarter and then add 3 months to get the end date. For monthly updates, you can use {{now.withDayOfMonth(1)}} for the start of the month, and .plusMonths(3) for the end date. It’s crucial to ensure your timezone settings are accurate, as discrepancies can lead to unexpected outcomes. I recommend testing in a sandbox environment first, as date calculations can behave unpredictably during leap years or at month-end. Keeping automation rules straightforward and separate from one another can help as well.