Hello all,
By now, I’m sure most of us have interacted with Service Manager in a small or large scale environment. With that assumption in mind, I’m going to assume that most of us have a well-rounded understanding of how Service Manager operates from an ITIL perspective and how it can be automated to provide many other kinds of functionality. While the tool provides management for multiple work item types, the majority of users that use Service Manager today create Incidents or Service Requests from an operational standpoint. However, I’m sure that most of us (including myself) do not interact with the other available work item types that Service Manager supports as often as Incidents or Service Requests. Yes, I’m talking about Release Records, Problems, etc. That’s not to say that organizations aren’t using that specific type of work item – there just isn’t a high demand for it and I feel like there is one work item type that most users should embrace… and that is a Change Request.
The way I see it, any change within an organization could provide significant value for the business. That’s why Change Management is really vital to the business so that management has insight into the quality and availability of services in their environment to essentially deliver a better product. With that being said, I recently wanted to see if there was a better way to ‘automate’ the creation of Change Requests. I found that a lot of the properties for a Change Request could quickly be added to the work item. Furthermore, additional information can be added to fields to capture even more data that the user may have and PowerShell does a great job of handling that data and placing it in those fields. If you feel that your organization receives more information than the average work item can hold, then extending a management pack to hold extra Change Request properties may be necessary to accommodate this.
Update-SCSMPropertyCollection and the SMLets
I started by importing the SMLets (which can be found here) as they play a big role with creating the objects and importing them into SCSM. I will mention that there was a module that I referenced in order to call a specific function, which is named “Update-SCSMPropertyCollection” (see below). This function essentially sets the correct ID prefix on the activities that were created from the change template. The reason why this function is needed is because the change object does get created but contains an incorrect prefix on each activity within the work item. These activities are added onto the object from the change template, but do not get updated correctly and that’s where this function comes into play in order to adjust and update all activities.
After starting off with caching classes and other enums, I wanted to get as much data as I could set up so I can later apply them to the work item object. To do this, I got random objects that are contained inside of variables and essentially appending them to the object down below. Additionally, I used a trick to get other random and unique data – I called the Github API to store objects in a variable which I pull data from and place on the title, description, reason, and implementation review.
