Automatically Creating Incidents Periodically

Automatically Creating Incidents Periodically

  • Comments 8
  • Likes

One question I hear pretty regularly is “How do I create a recurring work item every week (or day, or month, etc.)?”  The usual case here is that there is some task that needs to be done on an ongoing regular basis such as backing up a database, checking a log file, etc.  People are looking for a way to automatically create and assign that task to somebody at the appropriate time.  First of all this serves as a reminder to do important things at the right time.  Secondly, it makes sure that the completion of that task is tracked.

To accomplish this, I used to tell people to create a rule with a schedule data source module and a command write action module which would run a custom created .exe that called the Data Access Service to insert the work item.  That’s certainly a great option as long as you know your way around XML, C#, and our APIs on the Data Access Service.  If you have something sophisticated in mind, that might still be the best option.  However, if your requirements are simple, you are in luck because now we have the authoring console!

The rest of this blog post describes how you can create a new incident on a schedule using the authoring console.

First, install the Authoring Console. It is available at the same place you downloaded (or Connect) the Service Manager product bits.  Keep in mind that the VS shell needs to be installed first and there is a .bat file you have to run after installing the Service Manager authoring console.  See the product documentation that comes with the authoring console package.

Next, start up the authoring console.

Select File –> New –> Management Pack and provide a location to save your MP to and a file name.


Next, right click on the Workflow Rules node in the Management Pack Explorer tree and select Create Workflow Rule.


Provide a Name for the Workflow Rule like ‘CreateIncidentEveryDayRule’ and click Next.


Leave the ‘Timer’ option selected and click Next.


Provide the schedule you want to create the incidents on and click Next.


Provide a name for the Workflow such as ‘CreateIncidentEveryDayWorkflow’ and click Next.


On the confirmation page click Create.


On the completion page click Close.


Now you should see the workflow designer.


Drag the Create Incident workflow activity from the Toolbox onto the workflow design surface.


Now select that activity on the design surface.  In the Properties pane you will see a bunch of parameters.  Fill them out as appropriate.


Right click on the Management Pack in the Management Pack explorer and choose Save.

There should be a new .dll created in the same folder where you created the management pack .xml file.  Copy that .dll to the product installation directory on each Service Manager management server (if you have more than one).  The product installation directory by default is C:\Program Files\Microsoft System Center\Service Manager 2010.

Next import the MP into Service Manager using either the MP import experience in the Management Packs view in the Administration workspace in the main console or the Import-SCSMManagementPack PowerShell cmdlet.

An incident should be created within a few seconds and from that point on according to the schedule you specified.

Similarly, using the authoring console, you could create other workflows that run on a schedule or using a database query subscription that looks for certain conditions to be true in the database.

Let us know what you think!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Thanks Travis... below is a powershell script for any customers out there who want to auto create Change Requests. Same concept of creating the workflow in Auth Tool. You can set the title as noted to anything you want and set a workflow rule in the U I to apply a template. The below script also has a parameter to pass the scheduled start and end date into the work item. You can add any parameter you want here to pass into the initial creation.

    Import-Module Smlets

    $CrClass = Get-SCSMClass -name System.WorkItem.ChangeRequest$

    $Params = @{


           Title="SomeTitle: "




    $o = New-SCSMObject -Class $CrClass -PropertyHashtable $Params -pass

    $title = $o.Id

    $changeRequest = Get-SCSMObjectProjection System.WorkItem.ChangeRequestProjection -filter "Id -eq '$title'"

    $template = get-scsmobjecttemplate standard.*change



  • @Greg -

    Nice!  thanks for sharing! :)

    for others information - you'll need SMLets to do this.  get it here:

  • Additional Comment to the PS Script I mentioned. We discovered some issues with the "MA" or "RA" prefix appending to the activities contained in the template that you call in the script or at the U I Level. This really isnt a huge deal unless you are extensively using the exchange connector to approve or complete activities. The EC will not recognize a work item without the RA or MA in front of it. So, working with Travis, we came up with a work around. You need to add a Property Path command to your XML that contains the Template you are trying to call.

    Step 1: Locate the MP that contains the template that you are trying to call. If you are following SM best practice, this will most likely be in a custom created MP. If you used the out of the box unsealed MP to store your template e.g "ChangeManagement.Configuration.Library.xml" then you need to use the "CoreActivity!" command statements rather than "CustomSystem..." as noted below. Export the template and go into edit mode (note pad will work just fine)

    Step 2: Insert the following line of XML code into your MP. You insert this line of code just after the part of code where the template calls the review/manual ativities to be created:

                   <Property Path="$Context/Property[Type='CustomSystem_WorkItem_Activity_Library!System.WorkItem.Activity']/Id$">MA{0}</Property>

    Follow the same process for the Review Activities by replacing the MA with RA. I would suggest testing this in your test environment before deploying out to production.

    This solution works great for us as we have numerous changes that are routine and repeating maintenance activities. This automation takes the whole process of creating CRs much simpler for our organization.

  • Thanks guys! I was having that issue with the custom connector I created with CA Service Catalog.

    As you said... it's not a big deal... but I'd like people to use the Exchange connector to update those activities.

  • Hi,

    When I tried this, I get an error saying "System.Exception: No users found for the specified AffectedUserDomain and AffectedUserName" and so on....

    What username or account should I use there?

    Thanks in advance


  • With the changes to SCSM and the inclusion of Orchestrator is this still the best way to automatically create incidents?  Is there an option for Service Requests?


  • @Pattie -

    Orchestrator is a good way to do this as well.  I don't think I would say one way is better than the other.  There are pros and cons to each method.

    There isn't a Windows Workflow Foundation activity for creating service requests so you would need to use smlets similar to what Greg posted as the first comment to this blog post but change the class from System.WorkItem.ChangeRequest$ to System.WorkItem.ServiceRequest$

  • Is there a Automatically Creating Service Request Periodically guide line?