This post is part of a series on Service Manager PowerShell. Be sure to check out the Overview Page for all posts in this series.

In the previous post, Creating Configuration Items, we saw how to create configuration items using the Service Manager PowerShell Cmdlets. Now, in this post, we are going to look into creating work items with these Cmdlets.

Creating Work Items using the Service Manager PowerShell Cmdlets is very similar to creating configuration items, with one major difference. When creating work items you have to deal with the work item Id. Since creating configurations items and work items are so similar, I am not going to cover the detailed steps of determining the properties and creating the hash table to input the values you want to use. If you need a refresher on these items please refer to the Creating Configuration Items post.

As I mentioned earlier, when creating work items there are certain considerations you need to take regarding the work item Id. If you look at the properties of any of the work item classes, you’ll see that Id is a key field. This means that it is a required field and cannot be changed after creation. So how do you know what the next available Id is? Luckily, you don’t have to. You can use the value of “{0}” which tells the system to use the next available number.

*Service Manager Note
If you look at your Incidents in the console, you may have noticed that the Ids are not always sequential. This is because the Ids are set on the Work Item level, and not the inherited classes, such as Incident and Service Request. Therefore, every time any work item is created the work item Id is incremented. For example, if you create an incident and the Id is IR120, next you create a Service Request its Id would be SR121, then you create another incident, it would be IR122.

So using what we know we can create an Incident by setting the Id field equal to {0}, but there is a catch. If you actually run this, it will create the incident, however it will not contain the incident class prefix. So instead of creating incident IR125 it will create incident 125. To prevent this you can simply add the IR prefix in front of the {0}. So your id property would be set to “IR{0}”. You can see this in the example below.

As you know it is never good idea to hard code settings, like we just did with the Incident prefix. This is because different environments can have different prefixes. So to make your script truly portable and future proof, you should query the system to get the work item class’s prefix. To get the prefix for a specific class you need to get the class instances of the settings class. For the incident class the settings are in the class System.WorkItem.Incident.GeneralSetting. In the script below you can see the PrefixForId property being saved to the variable $prefix. The prefix variable is then added to the value for the Id property.

For your convenience, I have listed all the out-of-box work item class’s prefix settings below.

Now we can take this, and what we learned in the Working with Relationships post, and add different relationships to the work items we created. In the example below we are taking the same incident creation script that we used above, but this time we are saving it to a variable, then adding an Affected User relationship to it.

In this next example we are getting an existing Service Request. Then creating and relating a Manual Activity to it.

*Service Manager Note
You may have noticed the SequenceId property in the example above. The Sequence Id determines the order in which the activities are set in the parent work item, starting with 0. You will want to make sure that you are adding your activities in the appropriate order using this property. Therefore, if we want to add the new activity we need to know where to place it. To help with this I have written a function that can be used to add an activity anywhere in a parent work item.

All you need to do is pass the work item’s Id, then specify if you want your activity to be first, last, or in a specific position. If you use the First switch, it will increment every activity SequenceId, then return 0 for you to use as your SequenceId. If you use the Last switch, then it will simply return the next available SequenceId. If you use the SequenceId switch you will need to specify what position you want. Remember the first one starts at 0. The function will increment every activity greater than and equal to the one you specified, and return the SequenceId you entered.  Then all you need to do is set this returned variable as the SequenceId property in your script. The example below uses the same script we used to earlier to create the manual activity, but this time we are going to specify that it goes in SequenceId 3.

In this post you have seen how to create work items using the Service Manager PowerShell. Be sure to check the Overview Post for more content in this series.