So we're wanting to send a few different types of notifications to customers, depending on how long the issue has been sitting in the 'Waiting for Customer' Status.
The problem is, Notification 1 updates the ticket which resets the 'updated' counter.
So, how are we able to send the 1st Notification after 2 days, then the 2nd Notification after 4 days (and so on).
For example, the below logic does not work because after the first rule is run, it will reset the updated counter. The 2nd Notification would actually run after 6 days (2 + 4).
1st Notification - status = "Waiting for Customer" and updated < -2d
2nd Notification - status = "Waiting for Customer" and updated < -4d
I'm hoping that we could utilise something like the entity property field and leverage on this?
You might want to change the workflow, add some transitions that would not change the status but would update the "flag" and trigger notification.. Basically you need some field that would be updated to a new value on specific transitions and that value would be used later to set automation (not be based only on "updated" counter) .. then another transition would trigger if the flag is set to specific value .. etc.
1st Notification -> status = "Waiting for Customer" and updated < -2d -> execute a transition called "Notification1" and in a post function of this transition change the value of a field called for example Notification = Sent1
Then 2nd Notification would be based now on the field value not only updated (but we still need to track it just -2d not -4d) .. -> status = "Waiting for Customer" and updated < -2d and Notification = Sent1 .. this would again trigger another transition called Notification2 and in the post function of this transition change the value of a field called for example Notification = Sent2
3rd Notification and later is the same as above you just simply change the values of the field so that you are sure which transition would be executed next..
When reporter replies.. of course you change the status from Waiting from Customer automatically and clear the value of the Notification field so that you can start over again.
Hope it is clear :)
Thanks Mirek! I understand the concept but I'll need to do some testing.
Just wondering if there's any particular reason you recommend a transition for each notification stage as opposed to just updating a custom field this with a rule?
One negative I see with multiple transitions is it would clutter the transition button for the agents.
I proposed transitions since normally I do this with workflow (status) changes.. not in a single status.
Waiting for Customer -> Inactive -> Close
So if ticket is waiting without any reply.. I transition the ticket to Inactive and send a notification.. then if again ticket is not answered I simply add a different message and close with (with an option to reopen it of course)
I do not need 3rd level or more notifications.. but it would be also possible to add more of course e.g.
Waiting for Customer -> Inactive -> Pending Closure (Final Notification) -> Close
Everything depends on your needs :)
For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events