Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Staged Notifications

Hi All,

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?

1 answer

1 accepted

0 votes
Answer accepted

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.

Mirek Community Leader May 28, 2021

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 :)

Thank you.

Like Mirek likes this

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Site Admin
TAGS
Community showcase
Published in Jira Service Management

JSM June Challenge #2: Share how your business teams became ITSM rockstars

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...

226 views 7 7
Read article

Community Events

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

Events near you