Answered by:
Delaying notifications

Question
-
Hello,
I'm looking for a way to delay sending notifications.
I have two notifications being sent when an Incident is raised. One is going to the Affected User, second is going to the IT Team. I have a Runbook set up to allow IT Staff to raise Incidents on behalf of someone else. The problem that I am facing is that the notifications are being sent before the Runbook Activity is finished, and the notifications are sent with the wrong Affecetd User. Though it may also happen that the Runbook Activity is finished in between the 2 notifications, which ends in a situation when the IT Team gets the mail, and the IT person that raised the Incident is shown as the Affected User, while the real Affected User gets the correct e-mail.
The ideal solution would be to send the notifications about a minute after the Incident is raised. This would give the Runbook Activity enough time to finish and proper notifications would be sent.
I have also noticed that if I add the Priority to the notification, it may happen that the Priority is not calculated in time and is missing in the notifications. I thought I had this solved in a different thread but I was mistaken. So delaying the notifications would probably solve that problem as well.
Is it possible to accomplish what I'm trying to do?
Kind regards,
Wojciech
Tuesday, August 4, 2015 8:05 AM
Answers
-
To be safe I would remove the notification by SCSM and let the Orchestrator do the job for all tasks.
If you delay the SCSM workflow by x minutes it'S still possible that the issue apear.
Moving all worflows in runbooks or one runbook in Orchestrator is a secure way to do this in a consistent way.
Andreas Baumgarten | H&D International Group
- Proposed as answer by AndersAsp Wednesday, August 5, 2015 7:54 AM
- Marked as answer by Andreas BaumgartenMVP Thursday, August 13, 2015 9:07 AM
Tuesday, August 4, 2015 2:20 PM -
I'd love to use Orchestrator for that. I'm afraid it would be too hard for me to accomplish though, considering my (lack of) knowledge about this product.
I think I cam up with an alternative though. I'll try to make a copy of the default Incident class under a different name and use the new class for the Notification that's causing me problems.
We'll see how this goes.
Thank you for your advice.
Kind regards,
Wojciech
- Marked as answer by rozanw Wednesday, August 5, 2015 7:48 AM
Wednesday, August 5, 2015 7:48 AM
All replies
-
To be safe I would remove the notification by SCSM and let the Orchestrator do the job for all tasks.
If you delay the SCSM workflow by x minutes it'S still possible that the issue apear.
Moving all worflows in runbooks or one runbook in Orchestrator is a secure way to do this in a consistent way.
Andreas Baumgarten | H&D International Group
- Proposed as answer by AndersAsp Wednesday, August 5, 2015 7:54 AM
- Marked as answer by Andreas BaumgartenMVP Thursday, August 13, 2015 9:07 AM
Tuesday, August 4, 2015 2:20 PM -
You could remove the "Create Incident" notification, then add an "Update Incident" workflow & Notification with the "Changed from" - "Changed To" fields matching something that is set ONLY by the runbook to ensure the notification is only sent for Incidents updated by the runbook.
Let me know how you go.
Cheers.
ShayneRarma.
- Proposed as answer by AndersAsp Wednesday, August 5, 2015 7:54 AM
Tuesday, August 4, 2015 11:00 PM -
I'd love to use Orchestrator for that. I'm afraid it would be too hard for me to accomplish though, considering my (lack of) knowledge about this product.
I think I cam up with an alternative though. I'll try to make a copy of the default Incident class under a different name and use the new class for the Notification that's causing me problems.
We'll see how this goes.
Thank you for your advice.
Kind regards,
Wojciech
- Marked as answer by rozanw Wednesday, August 5, 2015 7:48 AM
Wednesday, August 5, 2015 7:48 AM