You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Hi all. I am looking for assistance on a custom JSM notification I've created in Legacy Automation that is not executing due to the JQL condition not being met.
I am a bit confused because the JQL query works when I type it in the search issues and successfully pulls up the issues that meet the condition. This is the query: (created >= startOfWeek("-1d") AND created <= startOfWeek("+1d"))
The query is checking for issues created on Saturday and Sunday.
My custom alert logic is simple:
When an issue is created,
if (created >= startOfWeek("-1d") AND created <= startOfWeek("+1d"))
then send an email
Thanks in advance for the assistance
@Natasha Richardson I would approach this a bit differently. I would make sure I have SLA calendars in my JSM desks are set correctly to match my Agents's schedules. Then I would use SLA JQL:
to filters issues whose SLA clock is not running according to the SLA calendar.
I hope this helps!
( More info about SLA related JQL: Using JQL queries specific to SLAs | Jira Service Management Data Center and Server 4.18 | Atlassian Documentation)
Thanks. Yeah, there are a few different ways to do this for sure and your approach seems much simpler. I may tweak it anyway because I didn't include after-hours for during the week. I asked Chat GPT and it gave me createdDate >= startofDay("America/Chicago") AND createdDate <= endofDay("America/Chicago") AND createdDate NOT BETWEEN startofDay("America/Chicago 08:00") AND startofDay("America/Chicago 17:00"))
This translates to tickets created outside of the specified business hours (8 am-5 pm) M- F in the Central Time Zone. It uses the NOT BETWEEN clause to exclude tickets created between 8 a.m.-5 pm M-F.
I didn't know you could directly specify a timezone in the query like that so that is pretty neat as well. I do have to consider different time zones with this setup for India, London, Poland, Brussels, Chicago, and some others.
This one ChatGPT wrote taking timezones into consideration but it says to replace the timezones with the relevant ones for your business hours.
createdDate >= startofDay("+05:00") AND createdDate <= endofDay("+5:00") AND createdDate >= startofDay("-7:00") AND createdDate <=endofDay("-7:00")
I'm not having much success with this feature. We have our calendars created and time to acknowledge and time to resolution SLAs set up. I'm using the legacy automation bc the format of the notification looks like the standard customer notification but for some reason the automation doesnt seem to be detecting the issues sla isnt running when i create a test ticket. I have today's date in as a holiday just for testing purposes and I've tried with '=' and '!='
Am I missing something here?
Answer accepted with one caveat, you will need to stack the re-fetch issue action to the automation otherwise, running this with the Issue Created option doesnt allow time for the SLA timer to be evaluated before the rule completes. Same goes for trying to evaluate the created date field.
This is a known issue:
Post on re-fetch
Suggesting a slightly clunkier approach from how I've set stuff up on our service desk.
For context, we track the day and month issues are created as custom fields for reporting and trend purposes using the following automation rule:
Following on from the above it would certainly simplify the JQL for your notification rule to be :
"Day Created" in (Sat,Sun)
Your JQL statement in your post should work for issues created in the most recent weekend, with a slight change though:
created >= startOfWeek("-1d") AND created < startOfWeek("+1d")
Can you share a (redacted) screenshot of your automation rule?
What don't you expect to see in the results?
Hi Kalin. Thanks for the response and yes, I want to capture tickets that come in over the weekend and basically send an email to the customer saying you've reached us after hours, etc.
When I removed this part 'AND created <= startOfWeek("+1d"))' the results returned tickets created on Monday. I am in Chicago so was testing this over the weekend last night. I created a ticket after Midnight and the JQL included that ticket when I removed the AND clause. Not what I want.
So the original JQL query works to filter only to Saturday and Sunday but for some reason, the Custom Notification I created didn't execute because it said conditions weren't met.
I wonder if maybe the rule is looking for the ticket to exist first and then evaluate the date? But that can't be right because it should be checked when the issue is created.
Screenshots of Custom rule attached
@Natasha Richardson Please follow up with your latest observations. Also, did you check your Jira's instance time settings:
OK, I tried so many workarounds its too much to type but ultimately with this query and the created date, the automation was executing too quickly before the rule could evaluate the conditions and thus my IF statement kept returning "no issues found to match condition" and sending the wrong email notification.
Since I also needed to implement this automation for holidays and after-hours during the week, I went with the solution suggested by Cassie and used withinCalendarHours(). I ran into the same issue though with the rule executing too quickly before the SLA timer could be applied. This is actually a known issue
I just found a workaround using the tidbit from these articles. I stacked the re-fetch issue option 10x before executing the IF and that worked. It is not pretty but gets the job done for me for now.
Thank you for describing your solution and the paths you took. Yes, unfortunately, there are less known issues with either automation (legacy and modern) that make us spend time troubleshooting them.
Yes, Cassie's solution is elegant plus your forcing a delay after the trigger.
Did you ultimately choose the legacy or modern Automation feature?