scsm 2012

SCSM 2012: Notification Subscriptions Vs. Notification Workflows

Hello again,

After having to deal with a lot of notifications in System Center Service Manager 2012, I thought I could illustrate the main differences between the two ways of sending notification emails.

Both Subscriptions and Workflows are translated into ‘Rules’ in the SCSM database, these rules are evaluated each time an object is created, updated or upon a certain period. So keep in mind, when it comes to rules, the less the better.

Comparison area Notification Subscriptions Notification Workflows
Scope Subscriptions can be scoped to a certain ‘Queue’ of Work Items. Workflows automatically apply to all instances of a specific Work Item.
Diversity Subscriptions can be created for any kind of instance in SCSM 2012, including Configuration Items as well as Work Items. Workflows can only be created for instances of these base classes and their extensions:

       ·        Activity

       ·        Change Request

       ·        Incident

       ·        Configuration Baseline

       ·        Release Record

       ·        Service Request

 

You can easily tell that you cannot even create a workflow for instances of the ‘Problem’ class

Events Unlike workflows, subscriptions add the ability to send periodical notifications as long as an object meets a specific criteria.

 

For example: You can create a notification subscription to keep notifying the service desk about incidents that are breaching your SLA.

Workflows can be only triggered in the following two events:

       ·        An object is created (optionally with specific criteria)

       ·        An object is Updated (optionally from/to specific criteria)

Functionality Subscriptions do not have any functionality other than notifications. Unlike subscriptions, Workflows give you the ability to apply templates to the objects that trigger them. Giving you a way to change any property of that object.

 

For example: You can create a workflow to automatically set an incident’s ‘Status’ to ‘Resolved’ when a certain field contains ‘Resolved’ keyword, by applying a template of the incident class with the ‘Status’ pre-set to ‘Resolved’.

Static Recipients Subscriptions have the ability to include static recipients to send the notification to. There static recipients are chosen from SCSM’s Configuration Items. Workflows cannot send notifications to static recipients, all the possible recipients must be directly related to the object that triggered the workflow.
Related Recipients When it comes to recipients, Subscriptions give you a much larger functionality than workflows in that area.

 

Subscriptions have the ability to choose a User recipient directly related to the object that triggered it, or from any of the User objects that has a relation with other objects with the object triggering the subscription.

 

For example: You can create a subscription to send a notification to the ‘Assigned To User’ of the ‘Change Request’ which has a ‘Contains Activity’ relationship with the ‘Activity’ triggering the subscription.

Workflows can only send notifications to the User recipients which are directly related to the triggering object.
Notification Templates One drawback of subscriptions, is that you can only choose one ‘Notification Template’ per subscription. Thus preventing you from sending multiple notifications to multiple recipients, each with a different notification template.

 

The workaround is to repeat the creation of each subscription once for each template, which can be tedious especially if you decide to change the selection criteria later, as well as the unnecessary rules that are created in the database.

Workflows allow you to choose multiple recipients, each with their own notification template.

 

For example: you can create a workflow, that when an incident is created, send a notification to ‘Affected User’ using ‘Notification Template A’, and also send a notification to ‘Assigned To User’ using ‘Notification Template B’, all with the same trigger.

 

The benefit is that way you can customize your notification templates to be much more personal to the recipient, thus including something like “Dear Affected User’.

 

And I think that sums it up. Will keep you guys posted in case I find any more differences 🙂

Advertisements

How To: Create SCSM 2012 Relationship Subscriptions for Email Notifications

Hello,

I ran across something during a SCSM 2012 implementation, thought someone else might find use for it.

For some reason, there is no way to create notification subscriptions that are triggered when the “Assigned To User” of a work item changes from the GUI.

After some digging around I found out that this feature is indeed available in SCSM, just not from the GUI, so you are going to have to do some XML editing.

So here is the simplest way I could do this…

First let’s focus on what information do we need to collect to be able to make this work.
1- The name of the relationship you are trying to subscribe to. (For example: Assigned To User)
2- The name of the source class, which is basically your work item that you want this to apply to (For example: Activity)
3- The name of the target class, which in our case is what kind class do you expect to be on the other end of this relationship (For example: User)

Now the actual values in XML might vary from one environment to another, this is why I cannot just upload a MP that does that for you. So here are the steps to do this on your environment.

1- Go to the ‘Administration’ pane, expand ‘Notifications’, and click on ‘Templates’, and have a notification template ready, because once you do this you will not be able to change the notification template for the subscription.

SNAG-0018

2- Go to the ‘Administration’ pane, expand ‘Notifications’, and click on ‘Subscriptions’, and click on ‘Create Subscription’ on the ‘Tasks’ pane. And create a new subscription for the ‘Manual Activity’ class. And specify the ‘When to Notify’ as ‘When an object of the selected class is updated’.

SNAG-0019

Note: Make sure you create a new Management Pack specifically for Relationship Subscriptions; preferably one for each, because it will later be easier to track down and update.

3- On the ‘Additional Criteria’ tab, Set ‘Changed From’ condition to anything. Just pick anything like ‘Status’ equals ‘Pending’ for example. This will later be replaced manually, but we need it to get a hold of the source class (Activity) in the XML.

SNAG-0020

4- Now go ahead an press ‘Next’, and choose the notification template you created earlier. And keep pressing ‘Next’ will you get to the ‘Related Recipient’ tab.

Now in our case, the source class is the ‘Activity’ itself. The target class is the a ‘User’. And the relationship class is the ‘Assigned To User’.

So I will choose to create just one ‘Related Recipient’ as follows:

SNAG-0021

Note: Why did I choose this recipient specifically, because it has a reference to the relationship and target classes that I need. Had I needed a different target class for example that does not happen to be a user, I would have had to create another related recipient specifically for that. All I actually care about here is getting the references of these objects in the XML.

5- Now don’t forget to add any other recipients you actually need to notify 🙂 because like the template you chose, those cannot be changed later as well. Unless of coarse with more manual editing.

6- Now after you are done with the subscription, simple go the ‘Administration’ pane, and click on ‘Management Packs’ then export the Management Pack you have saved this newly created subscription in.

7- Open the XML file you just exported with any text editor. Now let’s collect our class references from it before we start modifying.

Search for the following text in your XML:

<WorkflowArrayParameter Name="PrimaryUserRelationships" Type="string">

The following lines are the ‘Related Recipients’ you have chosen in the wizard. Now from these lines, extract the class references for your relationship and target classes.
For example:
My Relationship Class: CustomSystem_WorkItem_Library!System.WorkItemAssignedToUser
My Target Class: CustomSystem_Library!System.User

Great! you delete whatever ‘Related Recipients’ you do not need from the XML. And leave the others intact.

8- Now search the XML again for this portion:

<InstanceSubscription Type="7ac62bd4-8fce-a150-3b40-16a39a61383d">
<UpdateInstance>
  <Criteria>
	<Expression>
	  <SimpleExpression>
		<ValueExpression>
		  <Property State="Pre">$Context/Property[Type='CustomSystem_WorkItem_Activity_Library!System.WorkItem.Activity']/Status$</Property>
		</ValueExpression>
		<Operator>Equal</Operator>
		<ValueExpression>
		  <Value>{50c667cf-84e5-97f8-f6f8-d8acd99f181c}</Value>
		</ValueExpression>
	  </SimpleExpression>
	</Expression>
  </Criteria>
</UpdateInstance>
</InstanceSubscription>

Note the name of the source class, for example mine is:
CustomSystem_WorkItem_Activity_Library!System.WorkItem.Activity

Then, replace this whole portion with the following:

<RelationshipSubscription RelType="$MPElement[Name='CustomSystem_WorkItem_Library!System.WorkItemAssignedToUser']$" SourceType="$MPElement[Name='CustomSystem_WorkItem_Activity_Library!System.WorkItem.Activity']$" TargetType="$MPElement[Name='CustomSystem_Library!System.User']$">
  <AddRelationship />
</RelationshipSubscription>

Now note that I have put my relationship, source and target class references that I have collected in the little snippet as shown.

9- Finally, go to the top of the XML file, and increment the version number of this Management Pack inside the tag, this is a best practice but it won’t really matter.

10- Re-import the Management Pack to your service manager, and you are done! 🙂 Now whenever the ‘Assigned To User’ within any ‘Activity’ is changed, the ‘Assigned To User’ should get a notification email based upon your template.

Till next time 🙂