Sending Notifications When a Reviewer Votes on a Review Activity

Sending Notifications When a Reviewer Votes on a Review Activity

  • Comments 5
  • Likes

Let’s say you want to send a notification to a group of users every time a reviewer votes on a review activity.  How would you configure that?  Well – first of all you’ll need to use the NotEqual critera – see this blog post – to trigger the notification when the reviewers Decision property value before the update does not equal the Decision value after the update.  In other words the trigger needs to fire whenever the reviewer votes or changes their vote.  You can only configure this type of subscription criteria by directly editing the XML as outlined in the above blog post.

Once you make that modification in the XML though you can no longer edit the subscription in the console because the UI doesn’t know how to handle that kind of criteria.  You’ll get an error message that looks like this if you try to edit the subscription in the console:

image

Assuming you want to just use the MP XML file I am providing with this blog post to trigger this notification you can just use the criteria XML as is.  It looks like this:

                  <Criteria>
                    <Expression>
                      <SimpleExpression>
                        <ValueExpression>
                          <Property State="Pre">$Context/Property[Type='CustomSystem_WorkItem_Activity_Library!System.Reviewer']/Decision$</Property>
                        </ValueExpression>
                        <Operator>NotEqual</Operator>
                        <ValueExpression>
                          <Property State="Post">$Context/Property[Type='CustomSystem_WorkItem_Activity_Library!System.Reviewer']/Decision$</Property>
                        </ValueExpression>
                      </SimpleExpression>
                    </Expression>
                  </Criteria>

You will want to change the target recipient(s) though.  In the MP XML that I am providing with this blog post the recipient GUID is hard coded to the domain administrator in my dev/demo environment. 

                  <WorkflowArrayParameter Name="PrimaryUserList" Type="string">
                    <Item>eaf7f4e3-fbb2-a7f4-e588-0966e7580da7</Item>
                  </WorkflowArrayParameter>

You’ll want to query your ServiceManager database to the GUID(s) of the users or groups that you want to notify.  You can do that by running a query like this:

 

select basemanagedentityid from MT_System$Domain$User where 
Domain_E36D56F2_AD60_E76E_CD5D_9F7AB51AD395 = 'fabrikam'
and 
UserName_6AF77E23_669B_123F_B392_323C17097BBD = 'administrator'

Just change the domain and  username values to something appropriate for your environment.

You’ll get back a GUID that looks like this:

image

Just replace the GUID in the XML in the MP I am providing in this blog post with the GUID you get back from the user.  You can also add multiple <Item> elements inside of the <WorkflowArrayParameter> element.

Now you can import the MP.

If you want to you can customize the template.

To test, just vote on a review activity.  The specified recipient will see an email similar to this within a few seconds:

image

Management Pack download

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Before somebody asks - no, sorry, it isnt possible to put properties of the parent review activity or change request into the notification template.  we have a DCR for R2 that we will try to get to that will enable this scenario.

  • Hi Travis

    This formula works just when previos value is not null.

    Am I right?

  • @Vladimir -

    The subscription criteria will work whenever the value changes.  The value could change from null to Approved, null to Rejected, or even Approved to Rejected or Rejected to Approved.

  • Month ago I  tested this expression to setup subscription for setting up "Assigned to" in the incident. In this case it works when previos value was not null.

  • Sorry Vladimir - I don't understand.  "Assigned To" is a relationship type which would be a Relationship subscription criteria. The criteria in this blog post above is a Property subscription.

    When you subscribe to a relationship you subscribe to a relationship instance of a relationship type being created or deleted.  That's all you can do with relationship type subscriptions.  Is that what you mean by "not null"?