locked
Problem w/ e-mail subscription for Review Activities RRS feed

  • Question

  • Hi Experts, we're having some difficulty with a notification subscription, perhaps you can help us out? We have a "When an object of the selected class is updated" subscription targeting the Review Activity class -- the trigger being when the Status changes from any status to In Progress. The intention here is to notify all Reviewers within the Review Activity that they now have something to approve/reject.

    What we're finding though is that if the "Line Manager Should Review" flag on the Review Activity is set (which populates the Reviewers with the manager of the creator -- which we use a lot), that the workflow to move the Review Activity to In Progress fires BEFORE the workflow to add the Reviewer -- meaning that our subscription fires but doesn't dispatch an e-mail to the Reviewer (because there wasn't one set when the trigger occurred), and the manager has no idea they have something to approve.

    The time difference between these workflows when this issue occurs is on average around 30 seconds, but it doesn't happen all the time -- this issue only occurs about 25% of the time, the other 75% of the time, the workflow to add the Reviewer fires BEFORE the workflow to move to In Progress, and in that case we're in good shape.

    Thoughts? Suggestions?

    Thanks! 

    Friday, February 10, 2017 4:37 PM

All replies

  • What you're describing is a sequencing issue, which are easy to come across when working with parallel systems like SCSM.

    Basically, you have two workflows that trigger off the same condition..however, those two workflows need to have an explicit sequence (add reviewer, notify reviewer). However, thanks to non-determinism (a fancy computer science word..because it's Friday), you don't know which workflow will execute first.

    So, there are a couple options you can pursue, each with their own advantages and disadvantages. The first one I'll go over is, in my opinion, the easiest to implement and least complicated.

    This involves changing the trigger for your _notification_ workflow.

    Instead of triggering when the Review Activity goes In Progress, trigger when a "reviewer object" is created.

    Reviewer Objects sit in between the review activity and the reviewer, so there's a unique review object created for every reviewer added to any review activity. For example, if Bob is a reviewer for RA123 and RA456, there will be two reviewer objects. Both are related to Bob, one is related to RA123 and the other to RA456.

    When you change the trigger, you also have to change your notification template. It will have to target the reviewer object class.

    Here's the compromise: because the notification engine is limited to only two relationship hops in a notification, you won't be able to include any information from objects related to your service request (or incident or change request) because the SR/CR/IR is two hops away from the reviewer object.

    If you're interested in any of the other approaches, let me know and I'll describe them..but they do require some custom coding and/or Orchestrator runbooks.


    Aaron Croasmun - SCSM Customization Developer. If you have further questions, you can reach me at my gmail address: aaron.croasmun.scsm

    Friday, February 10, 2017 7:18 PM