Creating custom tasks in System Center Service Manager (SCSM) to send email notifications October 31, 2013 Sending email notifications regarding a working item in System Center Service Manager is a common requirement that doesn’t really exist out of the box. Travis had published, a while ago, a plug-in called “SCSM SendEmail”. This plug-in though filling that gap, still was missing some of the common requirements: Supporting only Incident – you cannot send email notifications about a service request Adding new email template required a new workflow and manual updates to the management pack XML, which means the end user cannot do it alone There is no way to send notifications to email addresses that do not exist in the SCSM user list. In my environment, for example, I needed to send the notifications to all the email addresses in a specific field of the work item Does not provide a way to “Set First Response” or change the work item status to “Pending” It has some multi users/messages reliability issues: When you are trying to send the same message content again, even if you are changing the template, it will not send it and there will be no indication that the message was not sent When you are trying to send a second message while the work item is open in the console, the first message will not be sent and there will be no indication as well When you are trying to send a second message while the work item is not open in the console and before the previous sending workflow has been started, it will send two emails but both with the content of the second message All these issues forced me to develop a custom solution (When I started to work on this, Travis’s project was part of the exchange connector and was not published as an open source). I built the console task “Send notification” and a supporting workflow, using the “SendEmail Activity” that I showed in my previous post, which solved all of the above problems and also allowed the console user to choose between the affected user and the assigned user as the email recipient. When you select “Affected Contacts” or “Both” as a recipient the email will be sent to the affected user and to any email address in the “alternate contact” field. The templates drop-down list shows all the email templates that relate to an incident/service request depending on the current item type, this way any end user, with the right permissions, can simply add more templates and with no delay start using them. In case the user tries to send a second message before the first one was sent, he will get a popup message to try again in a few seconds. The solution contains two management packs: C60.Incident.Notification.mpb – Contains the types’ extension to incident and service request. I’m using the same extension field’s names as in Travis’s solution, adding one extra filed called “MessageToAssignedUser” that sets the notification recipient Contains the “Send Notification” Console Task and a supported assembly. The package also hides the out of the box “Mark as first response” and “Request User Input” console tasks Contains empty email templates (the email body will include just the message from the dialog box) for incident and service requests that will be used when the user chooses “No Template” in the templates combo C60.Incident.Notification.WF.xml – Contains two workflows (one for incident and one for service request) that do the actual sending. Here is the workflow as shown in the authoring tool: The workflow’s trigger condition is when a work item’s “MessageTemplateId” field is updated from null to a different value. When executed, the workflow checks the “MessageToAssignedUser” field and based on its value sets the notification recipients: True – will send the notification to the assigned user False – will send the notification to the affected user / contacts Null – will send the notification to the assigned user and the affected user / contacts After the send email activity, the workflow will clear the “MessageTemplateId” field. To deploy the solution, just import both packages using the SCSM console and copy the content of the “SCSMExtension” folder to the SCSM folder (%ProgramFiles%Microsoft System Center 2012Service Manager). The “SCSMExtension” folder contains an assembly for each workflow and my custom workflow activity assembly. To open the workflows in the authoring tool you will need to deploy the custom workflow activities as described in my previous post. Get the source code and binaries for this article here