Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Adding business hours to an automation

Hello everyone, 


I have started this discussion because I opened ticket JSDCLOUD-6062. This is about adding an option to have the Time in Status automation count days as business days rather than business and none business days. 


The way we have our automation set up is after 2 days of the ticket being in Waiting for Customer it will transition to Inactive and then followed by Inactive 2 and Canceled.

This is a great feature and helps us not have to manage inactive tickets but the one drawback is if a ticket moves into an inactive status on a Thursday or Friday the process continues over the weekend when the person who has gone inactive is not working and it is not possible for them to reply. 

 If you agree that there should be an option for it to be counted over business days please go to the ticket and vote on it. 


Hey there, Cody


This can easily be accomplished by tying your automation to an expiring SLA (tied to a calendar of hours):


In this example, my calendar is set up with a typical spread of our business hours (7-5), and the clock starts each time the ticket enters that status. 

You could definitely set up a new SLA that starts each time the ticket transitions to make this work in your case. 

I'm not sure what the value add is for each of your status transitions through inactive. I set up 2 SLAs for our team, one of which is a ticket expiry notification at 8hrs in waiting for customer status and the other is the auto ticket closure at 16hrs in waiting for customer status. 

Like Tran Van Huu likes this

Hey Meg,


After setting up 3 different SLA's and automation this has successful worked. 


Thank you for showing me the correct way to do this!


Hey Meg,


That is great information and I really appreciate it! I've started working on this and I am wondering if you have to make individual SLA's for each status change or if it can all be in one? 

So far I got it to work with a single status change but I have a total of 3. 

I use one SLA for each status change. You could probably get it to work with one SLA, but it would have to 'restart' each time it hit your new status. 


Altogether, I'd say it's easy enough to manage for me in the multiple SLA route, but you may get some complaints about the SLA bar looking cluttered. Not a priority for me, but a consideration for others. 

My biggest problem with this solution is that I need the SLA to reset to 0 every time it has completed, otherwise when I use the SLA to ensure that customers respond in a timely fashion to any questions we have, the amount of time that the customer gets  to reply goes down each time because the SLA picks up right where it left off and not back at 0.

Hey @Corey Jepson - Not sure what you mean by this solution incrementing the customer's response. 

The way I have this implemented, the 'timer' resets each time that status is changed. 

I'd recommend checking on your SLA criteria and making sure it's set to 'stop' and not 'pause' the SLA when it changes status. 


Log in or Sign up to comment

Atlassian Community Events