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:
· Change Request
· 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 🙂