Workflow/Notification Subscription NotEqual Criteria Across Pre/Post Condition

Workflow/Notification Subscription NotEqual Criteria Across Pre/Post Condition

  • Comments 13
  • Likes

I’ve been meaning to blog this one for a while now.  Here’s the scenario…

Customer wants to be notified (or trigger a workflow) when the property changes from X to Y.  Easily done.  Just configure the subscription to be Before Value = X and After Value = Y.

Example:  Notify me whenever the incident urgency property changes from Medium to High looks like this:

image image

 

This notification will only trigger when the Urgency property changes from Medium to High.  Perfect!  Easy!

Now, let’s say that you want to notify when the Urgency changes from anything to anything else.  How do you do that in the UI?  Believe me – people have tried all kinds of crazy things they have sent me.  :)  The answer is that you can’t do this in the UI.  Trick Question!  You can do this in XML though.  Here’s the trick….

First – start out by creating a notification subscription (what I did for this example) or an incident event workflow rule or create a workflow rule in the authoring tool.  Here are the screenshots of what I did:

image

image

Then export the MP out (see here for information on hacking XML like a pro).  Open the MP .xml file in an XML editor.  Look for the Rule in there which you created.  Inside of it you will see the criteria XML that will look like this:

                <UpdateInstance>

 

 

 

                  <Criteria>

 

 

 

                    <Expression>

 

 

 

                      <SimpleExpression>

 

 

 

                        <ValueExpression>

 

 

 

                          <Property State="Pre">$Context/Property[Type='CustomSystem_WorkItem_Library!System.WorkItem.TroubleTicket']/Urgency$</Property>

 

 

                        </ValueExpression>

 

 

 

                        <Operator>Equal</Operator>

 

 

                        <ValueExpression>

 

 

 

                          <Value>{02625c30-08c6-4181-b2ed-222fa473280e}</Value>

 

 

                        </ValueExpression>

 

 

 

                      </SimpleExpression>

 

 

 

                    </Expression>

 

 

 

                  </Criteria>

 

 

 

                </UpdateInstance>

 

 

 

 

What you can see here is that the criteria is simply saying ‘Take the ‘Pre’ (i.e. before the update) value and see if that equals this GUID (represents the Medium Urgency Enum).  In other cases it might look a little different depending on your criteria.  What you need to do is change this to say ‘Compare the Pre value and the Post value. If they are not equal then trigger’.  Like this:

 

                <UpdateInstance>

 

 

 

                  <Criteria>

 

 

 

                    <Expression>

 

 

 

                      <SimpleExpression>

 

 

 

                        <ValueExpression>

 

 

 

                          <Property State="Pre">$Context/Property[Type='CustomSystem_WorkItem_Library!System.WorkItem.TroubleTicket']/Urgency$</Property>

 

 

                        </ValueExpression>

 

 

 

                        <Operator>NotEqual</Operator>

 

 

                        <ValueExpression>

 

 

 

                          <Property State="Post">$Context/Property[Type='CustomSystem_WorkItem_Library!System.WorkItem.TroubleTicket']/Urgency$</Property>

 

 

                        </ValueExpression>

 

 

 

                      </SimpleExpression>

 

 

 

                    </Expression>

 

 

 

                  </Criteria>

 

 

 

                </UpdateInstance>

I changed three things:

1) Change the Operator from Equal to NotEqual

2) Copied the Property State = Pre line and replaced the <Value>{Guid…}</Value> line with it.

3) In the second reference to the Property I changed the State from “Pre” to “Post”

Now I can just reimport this MP and it should start working as expected.

Note: As with any runtime changes you make to unsealed MPs, you’ll either need to increment the version number in the MP XML before import or restart the health service (System Center Management Service) before the change will take effect.

 

Note2: Not surprisingly, if you do this the UI will be confused.  If you open the properties dialog to edit the subscription you will probably see an error like this:

image

Hint: There are other tricky things you can do in Subscription Criteria XML that you can’t do in the UI like Relationship Add/Remove subscriptions.

My finished test/example MP is attached.

 

Apparently this reply to @jalass is too long to put in the Comments section below so I'll just add it to the end of the blog post here:

@jalass-

First of all - couldnt agree with you more on this needing to be in the UI.  We'll get there.  Just couldnt build Rome in a day.

Work Item Assigned to User is a generic relationship type between any work item class and the user class.  So - to subscribe to Change Request assignment changes you would just change:

    <RelationshipSubscription RelType="$MPElement[Name='WorkItem!System.WorkItemAssignedToUser']$" SourceType="$MPElement[Name='CoreActivity!System.WorkItem.Activity']$" TargetType="$MPElement[Name='System!System.Domain.User']$">

to:
    <RelationshipSubscription RelType="$MPElement[Name='WorkItem!System.WorkItemAssignedToUser']$" SourceType="$MPElement[Name='CoreChangeRequest!System.WorkItem.ChangeRequest']$" TargetType="$MPElement[Name='System!System.Domain.User']$">

In case it isnt obvious, I just changed CoreActivity!System.WorkItem.Activity to CoreChangeRequest!System.WorkItem.ChangeRequest.  In that case make sure you have an MP reference that maps 'CoreChangeRequest' to the System.WorkItem.ChangeRequest.Library MP like this:
      <Reference Alias="CoreChangeRequest">
        <ID>System.WorkItem.ChangeRequest.Library</ID>
        <Version>7.0.5826.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>

You could do the same thing for problems by changing it to CoreProblem!System.WorkItem.Problem and adding the right reference like this:
      <Reference Alias="CoreProblem">
        <ID>System.WorkItem.Problem.Library</ID>
        <Version>7.0.5826.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>

You can subscribe to different relationship types such as Created By and Affected User by looking up the appropriate relationship type ID and replacing that in the part that says WorkItem!System.WorkItemAssignedToUser above.  Make sure you have the right MP reference in place for the MP that you are getting the relationship type from.

Here is the info you need for the Created By and Affected User relationship types:

Created By Relationship Type ID: System.WorkItemCreatedByUser
Created By Relationship Type MP ID: System.WorkItem.Library

Affected User Relationship Type ID: System.WorkItemAffectedUser
Affected User Relationship Type MP ID: System.WorkItem.Library

BTW - Created By should never change.  :)

If you want to send a notification to a group you have two options -
1) Put the user in as the Affected User, Assigned To User and use the above approach.
2) Create a notification subscription (Administration - Notifications - Subscriptions).  Choose the group you want to notify in the recipients page of the wizard.  Note: the group must have an associated email address.  The export the MP and change the criteria as explained in the other blog post.  Reimport the MP.

 

 

 

 

 

 

Attachment: ManagementPack.d8fd96a9470c4942a127c3860ea377d0.xml
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Great information, very useful as usual!

  • Can this somehow be used to track assignment changes?  I am a tad frustrated with trying to get some of the core notification functionality up in Service Manager, particularly assignment.  I should not have to delve into XML and/or the Authoring Tool to accomplish something that should be core functionality of the product.  I'll stifle the venting now.

    I appreciate the XML provided for incident and activity assignment changes.  Can someone please provide the same for change requests?  In addition, I would prefer with these management packs not only to notify the Assigned To User, but also the Created By User/Affected User, both of which I am guessing have default GUIDs.  In addition, assignment changes like these are typically sent to our entire information systems group.  Can this somehow be accomplished through AD group membership or other means?

  • @jalass - see response at the end of the blog post above.

  • jalass - have a look at Administration > Notification > Subscriptions. You should be able to create a subsription that notifies a particular user or users or AD group when a job is changed to a particular group. It also means you can create one for each technician, so anything assigned to them using a field under 'Assigned to user' will generate an email.

    I'm also avoiding diving into XML because that's a long way from my area of expertise :)

  • Here is my thought.  I am going to create subscriptions for each technician to show an assignment change to that technician, with the notification going to our entire team.  For criteria, I have tried basing the Changed From/To on either 1) does not equal domain user name/equals domain username or 2) does not contain username/contains username, but notifications are not coming.

    What criteria combination should I use that will trigger the notifications?  With Changed From set to "Is Not Empty", notifications flow, but obviously extra notifications arrive when any work item update occurs.

  • @jalass

    re: your second comment - the reason the notifications arent coming as you are expecting is because the reassignment is actually two different updates to the incident - one to remove the relationship to the original assigned to user and another one to add the relationship to the new assigned to user.  When the first update happens (relationship removal) the From criteria is matched but not the To criteria.  When the second update happens (relationship add) the To criteria is matched but not the From criteria.   Unfortunately, for now, the only way to subscribe to these kinds of relationship transitions is to follow the blog post and use XML.

  • Please ignore my previous question, it works fine, just the crazy Outlook Junkmail filter moved my email...

  • Hi,

    i have a request similar to @jalass, but different.

    i would like to setup workflows that are relevant to certain AD groups, that would notify the affected user or manager.

    what i tried to do was put criteria of ADGroup equals ADGroupName in the console, but it didn't work.

    i can't use subscriptions, i don't think, as i would still need to email the affected user.

    i'm guessing i would need to do something in the XML, but can't be sure what trigger word i would use.

    any ideas?

    thanks

    Simon

  • @Simon -

    Are you looking for something like this?

    blogs.technet.com/.../custom-notification-workflow-on-incident-assignement-or-re-assignment.aspx

  • @Travis,

    thanks for the response.

    i have actually implemented that already, and it works very well.

    what we would now like to do is have a different notification for some departments in our organisation.

    the workflow i tried to implement had a rule that on create incident, if the affected user is in finance, send notification B to the affected user.

    this didn't work and they still get Notification A that the rest of the org gets, but also DON'T get notification B.

    i'm fairly sure i'm barking up the right tree using departments and rules, but i have a feeling i need to use the department GUID instead of the name.

    does that sound right, or am i over complicating it?

    thanks

  • @Simon - hard to say without looking at things in more detail.  Feel free to send me your MP XML file and a detailed description of what you are trying to do and I'll see if I can take a look at it.

  • Thanks Travis,

    i'm having a re-think in my approach, and might try to use powershell scripting.

    i've got a feeling that the workflow doesn't know what AD group the affected user is in, so i will run a script to get the Affected users group membership from AD, and then run the criteria check to see which alert they will get.

    anyone know if there is a way to put logging on workflows?

    wondering if that would help see the decision making....

    cheers

  • Oops,

    ignore me, i've been being a wally!

    initially i put the wrong name of the department, needed to get it correct from AD.

    then the workflow was failing due to an error on the notification template.

    all working now!