Video Screencast Help

Send Incident to Workflow: An Automation Rule Example Notifying Users of a Comment Added

Created: 07 Feb 2013 • Updated: 07 Feb 2013 | 2 comments
BRING's picture
+1 3 Votes
Login to vote

In ServiceDesk 7.5, Automation rules have been greatly expanded to add functionality and capability. Many new and interesting things are now capable that were not available before, and a lot of functionality that existed only by customizing a core process is now easily accessible to end users without an extensive knowledge of workflow components.

However, you can still leverage the power and functionality of Workflow to make changes to ServiceDesk incidents. This is done using the "Send Incident to Workflow" Ruleset Action.

The over function of this ruleset action is explained very well in another Connect article entitled "ServiceDesk Customization: Send Incident to Workflow Ruleset Action". This article is simply using that function to provide an idea or example of one that that functionality can be used to improve and customize ServiceDesk 7.5 to meet changing business requirements. This article assumes average workflow knowledge, including the knowledge to create and configure a workflow model and to be able to publish the model to your server.

The premise of this article is to show how you configure your ServiceDesk system to send a notification email to any member of an assigned Service Queue for an incident that has had a comment added by the Affected User, and/or any user has a subtask assignment.

To do this, you should review and follow the process outlined below:

  1. Complete the Workflow Design
  2. Capture the configuration information for the Automation Ruleset from the Workflow Model
  3. Configure the Automation Ruleset and Rule
  4. Test

Complete the Workflow Design

We have provided a sample package for this project which provides the workflow functionality required. Of course you may want to change or build your own. Key items to remember are:

  1. In your project, setup Input Data to capture the Workflow TrackingID from Servicedesk. This will allow you to correlate your work to a specific incident ID. This is created as shown below.

  2. Assure that you name your project something meaningful. We chose "CommentAddedLogic"
  3. In our sample, we used a component called "GetProcessHistory". If you use this component, it must have all options checked under the Process Messages and User Comments tabs. Under the General tab, please make sure Status Changes are checked, but leave "From CurrentProcess" unchecked. This is shown in the screenshots below.

  4. One caveat that might be a little challenging. You cannot access an email template from within this new external workflow, so you will use a Send Email component to notify the users. You should make this match the format and style of your email templates from other automation rules.
  5. When you have your workflow process configured correctly, you should test. This can easily be done using Workflow's built-in debugger. It is recommended that you take a couple of test incidents and create comments on those incidents, then copy the exposed workflow tracking ID from those incidents to the correct prompt when executing your process. That trackingID is found in a location similar to the screenshot below.
  6. Once you have assured that the emails are working correctly, you can publish the application to your server. Make sure that the Virtual Directory is properly titled. You should also capture this Virtual Directory name to a notepad page. You will use this later.

Capturing Configuration Data for the Automation Ruleset from the Workflow Model

There are a couple of items that you will need to capture from the Workflow publishing tab, prior to closing the project.

  1. In the tree view of your project, browse to the top level of the project. You will see the various properties tab of the project, as shown below. Select the Publishing tab.

  2. On the Publishing tab, scroll down to the Primary Service section and capture the Service Name and Method Name entries. Copy them to the same open temporary notepad space you opened up earlier. You will use them later.

Configure the Automation Ruleset and Rule

Now, with the project published and the key values for the automation rule ready to be used, you can open the portal and configure your automation rule.

  1. Open the portal and login in as an Administrator.
  2. Browse to the Admin>Automation Rules menu choice
  3. Expand the Incident Management Ruleset list, and click on Service Dashboard
  4. Click Add Ruleset
  5. Define the Ruleset similar to what is shown below. Provide a Title and Description. You should make sure that you select the Data Event radio button, and then choose the CommentAdded event. You can leave all other options at default.
  6. Click Save. This completes the creation of the Ruleset.

  7. Now we can create the actual automation rule. Expand your newly created Ruleset (if needed).
  8. Click on the lightning bolt to the far right of your new rule set.
  9. Click Add Rule
  10. 1You will see the Add Rule Screen, similar to below. You can create any condition that meets your needs. Our example simply shows the "ANY" condition used.
  11. In the Actions section, select the "Send Incident to Workflow" option, and then use the "At URL" option. Enter the URL of the WebService created while publishing, without the actual extension. This will be in the form "http:\\Server_Name\Published_name ". This is the published name you captured while sending the workflow project to be published to the web server, in your notepad.
  12. In the Parameters: section, copy the Workflow Service Name you copied from the publishing properties you captured in the earlier configuration section, step 2. This goes in the Workflow Service Name option here.
  13. You will need to copy the Method Name captured earlier to the Workflow Start Method Name field here on this page. The method captured in the earlier configuration section, step 2, as well.

  14. Now click Save.
  15. This completes the automation rule configuration section.


You should test this process with different users, members of Service Queues, and those users with subtask assignments. You may need to design different capture methods to capture other types of users as well.


This is simply one example of how you can use the "Send Incident to Workflow" automation rule option to improve or add functionality to Servicedesk 7.5. Please take time to review the process, review the libraries included, review the variables used and how they interact.

Comments 2 CommentsJump to latest comment

BRING's picture

One other item to note - you can add a Switch to Async component and accelerate the performance of this flow.  However, if you change any incident data, you won't want to add the Switch to Async component, as this could result in data inconsistency.

Login to vote
mih182's picture

Thanks for the AddCommentLogic workflow.

I have two items pertaining to this workflow. Firstly, the workflow almost works as expected. I was testing this, and noticed that when a comment is added to an incident with the Public view, the AddCommentLogic doesn't detect a new comment on the incident. However it does work fine when Admin or Private is set at the Comment view. Thoughts?

Secondly, I have changed the EmailMonitor workflow to add email replies as Comments on the incident. This works great. However when I invoke the AddCommentLogic workflow, it doesn't detect the new comment added to the incident via the email. I have tested the email reply comment being set to Public, Private and Admin view, and still no luck with the AddCommentLogic detecting the new comment.  If I manually edit the email response comment and change the view to say Private, the AddCommentLogic picks up the comment no problem. Thoughts?


Login to vote