Happy Thursday, everyone. Last week I presented a session at the Saint Louis System Center User Group about a workflow solution I devised for a common pain point in Service Manager which leveraged Orchestrator and PowerShell. At the time, I lamented that the structure of the solution in Orchestrator (multiple “sub-task” runbooks being invoked from a parent “process” runbook, stored in different folders), while following best practices, made it challenging to distribute out to the community. I then demonstrated an updated version of the solution condensed into a single PowerShell script that could easily be deployed via Orchestrator, Service Management Automation, or as a Workflow within Service Manager itself. I also committed to packaging the script into a Service Manager Workflow and passing it along here on the blog. Here is that post! Follow along as I detail the problem, how the solution addresses it, and how to get it up and running in your environment via the management pack I’ll provide at the bottom of the post.
The Problem
The core problem being addressed is the ability to provide information about parent work items in notification emails sent to reviewers and activity implementers in a way that provides them with the information they need to do their job while reducing complexity and resource utilization.
For those who aren’t already aware, sub-tasks within a process (such as approvals and implementation steps) are stored in Service Manager as separate child work items called Activities all contained within a single parent Request work item. This is useful because, instead of hunting down a collection of tickets relating to a single process (such as new user provisioning), the parent work item provides a centralized point of access to all of the steps in the process. Because the type of work item is different between the Activities and the parent Request, too, there is no chance of confusion about whether or not a ticket is a parent or a child within a process.
As with any object in Service Manager, notification emails can be triggered when said object is created, updated, or meets specific conditions. This includes the Activities – it is very easy to configure a notification email to let the assigned approvers know when a process has reached an approval activity and they need to grant or reject approval. When configuring the format of the notification email, it is easy to use substitution strings to add details from the specific ticket into the email. The place where it gets tricky is inserting properties from the parent Request work item into the Activity’s notification emails. This is do-able out of the box, though not always straightforward – This post on the Service Manager Engineering Team Blog walks through the process. While that solution works, and for many cases, works fine, it contains three specific weaknesses or limitations that warrant another solution:
- The GUI only displays certain properties from the parent work item to insert. While it is possible to insert others, the admin configuring it must know the internal names of the other properties as well as how to properly format a substitution string.
- The GUI only allows you to insert properties from the work item one tier up. If an activity is contained within another activity, the admin would again need to manually configure the substitution string to get the parent Request work item’s information to be inserted in an email.
- When configuring the notification template, the admin has to know precisely where the information they want to insert is stored on the parent request. If different types of requests store required information in different places, then either unique notification templates and workflows have to be configured for each request type, or email quality must be sacrificed, either by not displaying all of the information or potentially displaying blank values.
These issues become much more apparent when an organization starts implementing their Service Catalog and leveraging the configuration of Service Manager’s Request Offerings. When any given request can present a different number of questions to end users, when the answers to those questions can be saved in different places for each request type, and when different types of requests store data in the same fields, it becomes impossible to configure functional notification emails for approvers and activity implementers without sacrificing data quality or building individual notification workflows for each request type. Building individual notification workflows quickly becomes unmanageable and would have a detrimental effect on the whole system – when hundreds of workflows are checking the database every 60 seconds to see whether or not they should take action, system performance will plummet. Additionally, when the goal is to minimize the work employees need to perform to get information out of the system, I don’t think that sacrificing email quality and driving them into the system to get the information they need to do their job is an adequate solution.
This scenario presents a problem, but the problem is hardly insurmountable. This is where my solution steps in.
The Solution – Dynamic Population of Parent Request Data to Activities
The root of the issue is the need to make an activity’s parent Request’s information easily available to notification workflows triggered by an activity while accounting for the following:
- the uncertainty of whether any given activity will be directly related to the parent Request work item versus related via one or more other activities
- the uncertainty of how many questions and their answers will be contained in any given request type
- the uncertainty of where those answers will be stored and what those questions will be
The way to solve the issue is to take all of that data and simply store it on each activity itself. In this way, the activity’s notification email only needs to have one property inserted, and that from the activity itself, to have all of the required parent work item information available in the email for any recipients to review and use immediately.
Fortunately, all of the data needed is stored on the parent Request work item, so all that is needed is to collect it from each of its locations, format it into a single block of text, and insert that into each activity. I have written a script to do just that, then leveraged that script in a collection of workflows in a management pack to enable the functionality for different types of work items in Service Manager. What the script does is mine a given parent Request work item for relevant information – ID, Title, Affected User, Assigned User, Assigned Support Group, and the request offering Questions and Answers – arranges them into a block of text, then appends that text to the Description field of each activity contained in the parent Request work item, whether directly or by way of other activities.
The most interesting part of the script is how it collects the questions and answers provided for each request type, regardless of the quantity and type of questions configured in each request offering. As stated above, each request offering can have different quantities of questions and can have the answers mapped to various properties on the resulting Request. These can be out of the box properties or custom properties, located on the parent request or directly on the contained activities. The process to collect all of these answers regardless of their location would be a huge ordeal if not for one fortunate fact – regardless of to which property the answers are mapped, ALL question and answer values are stored within a single property on the parent Request work item, titled “UserInput”. The questions and answers are stored as a block of XML which contains all questions, answers, and data types configured in the request offering spawning the Request and answered by the submitter. By leveraging PowerShell’s XML Reader, it is possible to extract the data and convert it into useful information for the overall workflow.
I plan on providing a follow-up post which goes into detail on how the script works, but for now, I am going to provide instructions on deploying it so that you can begin leveraging it in your own environments.
How to Deploy the Workflows
First off, this workflow requires SMLets to function. Before anything else, SMLets will need to be installed to your Primary Service Manager management server. This is the management server which runs all SCSM workflows. If you have multiple management servers, it will be the first management server which was installed, barring a custom modification. If your intent is to leverage the script alone via Orchestrator or SMA, SMLets will still need to be leveraged. Make sure it is installed and configured first before proceeding any further.
Now that that is out of the way, to begin, you’ll need to download the ZIP file I have linked at the end of this post. Inside, you’ll find three folders:
- Authoring Tool Workflow Files – This folder contains the .cs, .xoml, and .xomlx files generated by the Service Manager Authoring Tool when constructing workflows. These files are only needed to open and edit the workflow within the Authoring Tool.
- Management Pack and DLL – This folder contains the unsealed management pack “MTS.Workflow.WorkItemDataPopulation.xml” as well as the compiled “MTS_WorkItem_DataPopulation_toActivities.dll” assembly which contains elements of the workflow.
- Script – This file contains the script used by the workflow, in case you’d like to use a different tool (Orchestrator or SMA) to deploy the workflow instead of via the management pack.
To deploy the workflows, first, the DLL must be copied to the Service Manager install folder on your environment’s Primary management server. Here is an image of the DLL having been copied to the requisite folder in my test environment:
Next, the management pack must be imported into your Service Manager environment. Here’s an image of the management pack post-import as viewed in the Service Manager console:
Finally, you must enable the workflow for whichever work item types you would like. Each workflow has a common back-end which performs the work (running the script), but a different front-end for each of the primary work item types which support activities. This can be done via the Administration workspace -> Workflows view -> Status view, as seen in the following image:
Note that there is a workflow targeted at the core Work Item class; it is not recommended to use this workflow, but instead use the other class-specific workflows.
All of the workflows are disabled by default so that you have full control over what the workflow affects. Simply enable it and create a new request to see it in action! Here is an image of the workflow’s result, as seen within a Manual Activity:
As you can see, the parent Request work item’s information, including request offering questions and answers, has been added to the activity’s Description property. Now, any notification templates from the Activity only need to display the activity’s Description property to also include all the relevant information from the parent Request, enabling users to review information at a glance instead of needing to open the Console or the Portal to review an existing work item.
Closing Thoughts and Download
This is a useful solution which can help decrease notification workflow complexity while providing greater value to activity implementers and approvers in your environment. Still, I have a few ideas on how to improve the solution in the future, so keep your eyes and ears open for future updates.
Standard disclaimer: This management pack and its contained workflows and script are not provided by Microsoft and is thus not supported by Microsoft. ALWAYS test any scripts you find on the internet in your Test or Development environment before using in Production!
Along with this post, I have also published this script on Technet. Use the following links to view the script on Technet or to download it directly from here:
https://gallery.technet.microsoft.com/Service-Manager-Workflow-0a40d8a7
Data-Population-to-Contained-Activity-Workflow-MP.zip
