Activities Stuck in Pending Status

Occasionally you can get a Change Request or Service Request that has activities stuck in a pending state.  This can occur for a variety of reasons the most common of which are:

  • You use PowerShell that creates the Change or Service Request, and then applies a template that contains activities
  • You manually apply a template with activities in it
  • You use PowerShell or Orchestrator to create a Change or Service Request and set the status of the Change or Service Request to “In Progress”

Thankfully there is an easy fix without hacking individual activities.  Put the parent Work Item (Change or Service Request) On Hold, then wait for all child activities to also take the On Hold status, then change the parent Work Item status to In Progress.

This can be achieved manually through the console, or via PowerShell.


SCSM HTML 5 Portal – Customise the Size of a String Property

When a string property is used in a Request Offering it is displayed as a small single line text box in the portal.  It will auto expand as the user types, however it doesn’t accept carriage returns.  If you hit the Enter key from the text box you will submit the Request Offering instead.

To resolve this add the following code snippet to the MakeForm.cshtml located in C:\inetpub\wwwroot\SelfServicePortal\Views\Home.

else if (item["Prompt"].ToString().Equals("Description"))
    string regexToolTip = string.Empty;
    if (item.ContainsKey("ToolTip"))
        regexToolTip = item["ToolTip"].ToString();

    <label for="@item["Prompt"].ToString()" data-required="@item["Optional"].ToString()">@item["Prompt"].ToString()</label>
    <textarea cols="40" rows="10" name="@item["PathSend"].ToString()" id="@item["Prompt"].ToString()" @item["Optional"].ToString() value='@Request[item["PathSend"].ToString()]' data-toggle="tooltip"> </textarea>
<div class="error-text">@ErrorResults.Find(m => m.MemberNames.ElementAt(0).Equals(item["PathSend"].ToString()))</div>

It must be inserted before the ‘else’ statement that is at the end of the fav_name_email section.  This section is towards the end of the file and looks like this:

<div class="fav_name_email section">
  @foreach (var item in formData)

The key part of the code snippet is in the first line.  In this example I have used “Description”.  It must match the name of the question in the Request Offering.  For example if you have used “Please enter a description” as your question, then the line must be:

else if (item["Prompt"].ToString().Equals("Please enter a description"))

It is also case sensitive.

N.B. it is advisable to backup the files before modifying them.  The Portal Updates patches are designed to read the date stamp on the files and compare it to the last update installation date.  If they match then the file will be overwritten, if they don’t match (I.E. you’ve edited them) then they won’t be updated.  So prior to any update copy the default files back in first.  Yes, there is potential that all your changes will be wiped out by a patch.

The problem here is that you have to add the code snippet for each string value you want to use (assuming you don’t want the default text box) for every question that is worded differently.  It is easier to use a simple common term in your Request Offerings such as “Description”.

This code works with Update 3 for the System Center 2012 R2 Service Manager HTML 5 Portal.

So now that the text box is larger, and accepts carriage returns the font needs to be updated otherwise it will look like type writer text.  To do this add the following code snippet to a file called Custom.CSS and drop it in C:\inetpub\wwwroot\SelfServicePortal\Content\CSS

.section textarea {
 font-family:”Segoe UI”;
width: 24em;
 border:1px solid #BBB;

Automatically Adding the Customer Company CI When an Incident is Created – Workflow Authoring – Part 2 Authoring the Workflow

Automatically Adding the Customer Company CI When an Incident is Created – Workflow Authoring – Part 1 Constructing the PowerShell Script

Automatically Adding the Customer Company CI When an Incident is Created – Workflow Authoring – Part 2 Authoring the Workflow

In part 1 we defined a PowerShell script for automatically obtaining the IR and the Customer Organisation CI based on the Company property of the Affected User.  In part 2 we will plug that script into a workflow.

Creating the Workflow

New MP

First thing you need to do is create a new management pack to contain your workflow.  I’m a big fan of separating out Classes, Forms, and Workflows into separate management packs, and group them together. Indeed it is best practice to place your forms into separate management packs from your classes. This approach can make it easier to decommissioned a feature at a later date, as importing an updated MP that has had a class, form, or workflow deleted from it is not supported.

 New Workflow

Now Create a new Workflow called something like “UpdateIRwithCustomerOrganisation”

Give it a name and a description:


Set the condition.  In this case we need it to run on an ‘as required’ basis.


Finally select the class and criteria.  We want our workflow to trigger when an Incident is created.


You should finish up with an empty workflow in your Management Pack.


Next you’ll need to drag out a PowerShell script activity from the Toolbox.  For this demo we only need one script activity.  Give the script activity a more user friendly name.  In this case I’ve used “PowerShellUpdateIRwCustOrg”.  You can’t add spaces in the activity name using the Authoring Tool, usually I would edit the XML to do this, but for the purposes of this post I’ve left it as is.


Now we need to configure the parameters and body of the script.  To do this click on the radial button next to “Script Body”.

First lets setup a variable for the IR.  Give it a name without using the $ character.  In this case I’m using IRID.  Then select the ID property of the Incident class using the radial button.  When you’ve finished it should look like this:


Now onto the PowerShell script itself.  This is a simple case of writing or pasting in your script into the Script Body of the PowerShell Activity.


N.B. You can see that the first line of the script in the body is to load the SCSM PowerShell cmdlets.  Some of you may be asking why I’m not specifying it in Script Properties of the PowerShell Activity – simply because it’s not supported for this module.

You’re All Set!

Now all you need to do is seal your workflow Management Pack and import it (including the Customer Organisation if you’ve been following along).

When your Incidents are created the Customer Organisation CI relationship will automatically be populated!  Happy automating!