locked
Incident workflow retroactive after being re-enabled? RRS feed

  • Question

  • I've been bitten by this twice now. The damage is done, but I need to know the technical reason for why. 

    I disabled my resolution notification workflow when switching to a 3rd party send email solution a few months ago. After ditching the 3rd party tool, i needed to re-enable the workflow. I made sure all resolved incidents were in a 'closed' status before re-enabling the resolution workflow. And just as i had feared, it immediately starting sending out retro-active Resolution emails for old incidents. 

    Was my first mistake re-enabling an old workflow? Should I have just created a new one? My criteria is Incident Updated from status does-not-equal resolved to status equals resolved AND status does-not-equal resolved/cancelled

    Friday, February 10, 2017 1:33 AM

Answers

  • Hi

    Yes, we have all probably been bitten by this at one stage or another.

    Deleting the subscription and recreating it would have avoided the problem. But is a hassle and other mistakes can be made.

    I wrote a blog post on a possible solution: SCSM Subscription Testing mainly with testing subscriptions in production environments, but applies equally to this case.

    When you re-enable a subscription it is going to start evaluating work items from when you disabled it - NOT as you would expect from the date when you re-enabled it.

    So you end up with a lot of emails going out about jobs that met the criteria for a period in the past, but don't now. Certainly not what you expect to happen. And can cause a lot of confusion to the users receiving the emails.

    So, if you have a friendly Exchange admin (and aren't all Exchange admins friendly) you can create a transport rule that captures all the subscription emails before they are sent to users etc.

    Add a key string to the subscription template, say [UAT Testing] and get the Exchange Admin to create a rule that captures this from the subject line and redirects it to another mailbox. Have them narrow it to emails from the SCSM work flow account and there is no chance of false positive hits.

    Now re-enable the subscription, wait for the hundreds possibly thousands of emails to come in. Then take the string [UAT Testing] off the template and it is now back in "production" with emails going where they need to.

    This has been very useful for user acceptance testing where we want to test subscriptions that has production users in them, but we don't want them to receive the notifications and approval requests. Once the transport rule is set up, the SCSM admins have control (add or remove it from the template) of where the emails go.

    Regards

    Glen



    Web: www.xapity.com  |   Twitter: @xapityapps  |   Facebook: xapityapps

    • Proposed as answer by Stoyan ChalakovMVP Friday, February 10, 2017 9:10 AM
    • Marked as answer by STL_ITdude Friday, February 10, 2017 3:15 PM
    Friday, February 10, 2017 5:42 AM

All replies

  • Hi

    Yes, we have all probably been bitten by this at one stage or another.

    Deleting the subscription and recreating it would have avoided the problem. But is a hassle and other mistakes can be made.

    I wrote a blog post on a possible solution: SCSM Subscription Testing mainly with testing subscriptions in production environments, but applies equally to this case.

    When you re-enable a subscription it is going to start evaluating work items from when you disabled it - NOT as you would expect from the date when you re-enabled it.

    So you end up with a lot of emails going out about jobs that met the criteria for a period in the past, but don't now. Certainly not what you expect to happen. And can cause a lot of confusion to the users receiving the emails.

    So, if you have a friendly Exchange admin (and aren't all Exchange admins friendly) you can create a transport rule that captures all the subscription emails before they are sent to users etc.

    Add a key string to the subscription template, say [UAT Testing] and get the Exchange Admin to create a rule that captures this from the subject line and redirects it to another mailbox. Have them narrow it to emails from the SCSM work flow account and there is no chance of false positive hits.

    Now re-enable the subscription, wait for the hundreds possibly thousands of emails to come in. Then take the string [UAT Testing] off the template and it is now back in "production" with emails going where they need to.

    This has been very useful for user acceptance testing where we want to test subscriptions that has production users in them, but we don't want them to receive the notifications and approval requests. Once the transport rule is set up, the SCSM admins have control (add or remove it from the template) of where the emails go.

    Regards

    Glen



    Web: www.xapity.com  |   Twitter: @xapityapps  |   Facebook: xapityapps

    • Proposed as answer by Stoyan ChalakovMVP Friday, February 10, 2017 9:10 AM
    • Marked as answer by STL_ITdude Friday, February 10, 2017 3:15 PM
    Friday, February 10, 2017 5:42 AM
  • Hi Glen,

    very interesting approach. Thanks for sharing

    Regards,


    Stoyan (Please take a moment to "Vote as Helpful" and/or "Mark as Answer" where applicable. This helps the community, keeps the forums tidy, and recognizes useful contributions. Thanks!)

    Friday, February 10, 2017 9:12 AM
  • Thanks Glen! I think you might of helped me with this a few years back when I botched a subscription with an "or" instead of an "and". I ended up shutting down SM, creating a transport rule and firing it back up. 

    Thankfully this workflow was disabled in January, so it wasn't as bad as it could of been. 

    Friday, February 10, 2017 3:15 PM