top of page
  • Glen (Xapity)

SCSM Console Views

Views allow Analyst to see work items in Microsoft Service Manager (SCSM). This blog outlines the steps to customize views and make use of tokens to make your views work better in Service Manager.

Management Packs (MP)

When you create a view you need to store it in an unsealed Management Pack. An unsealed management pack can accept updates and this allows the view to be edited once it has been created. You can create a Management Pack when you create the view and this will have a nice display name, but when you export it the filename will be in a GUID format.

I would recommend using the Service Manager Authoring tool to create a new management pack that has a friendly file name and display name. Import this into Service Manager before you create the view.

SCSM View Criteria

It is also possible to have multiple views and store these in multiple management packs. I would tend to make a management pack for each work item type - Incidents, Change, etc. In some cases you might also consider a new management pack for different Support Groups if they have a large number of views. But with more management packs, you create administrative overhead, so don't go overboard.

I would recommend starting with a test management pack that only has one view in it while you are testing and making XML changes - it just makes it easier to edit and understand what the XML is doing.


There are pre-defined tokens that can be used as variables in the criteria of a view (or in other areas that use the Service Manager criteria builder eg email subscriptions). Using these can reduce the number of views required and make the views more dynamic.

  • [me] – current user based on ID, requires editing XML

  • [mygroups] – uses current user’s AD group to match to property where the group has been populated

  • [now] – current time, use relative option in the criteria builder

Some blogs reference a [today] token, but I could not get this to work in my testing.

The token [now] is the most user friendly, as it is supported in the GUI criteria section of the view builder. Examples:

  • [now + 15s] - using seconds (s)

  • [now+ 10m] - using minutes (m)

  • [now – 4h] - using hours (h)

  • [today -7d] - using days (d)

Unfortunately there is no token for Support Group. It is a common request to have views based on the support group that the analyst is associated with. The only option is to create views for each individual Support Group and this does create a lot (potentially hundreds) of views. By using Security Roles, you can restrict what views analysts see to just the Support Groups they are associated with. Using one folder to hold all these views can be useful to keep the console tidy for Admins (who will see all views).

Support Groups are a problem because they are just a list with no association or relationship with an analyst. Check out Xapity Teams as this creates a relationship between and AD group and the support group.

The [mygroups] token sounds promising, but it does not work the way you might expect. This is best illustrated by using a specific example of Assigned To User (but this applies to any of the other user fields eg Affected User, Primary Owner)

Example: we have two analysts, Glen and Sam, that are a member of the IT Messaging group. This group and the users have been captured in the CMDB by the AD connector.

Service Manager has the Following Incidents:

  • IR21 Assigned To User = Glen

  • IR23 Assigned To user = Sam

  • IR26 Assigned To User = IT Messaging

The [mygroups] token for Glen will show IR26.

The [mygroups] token for Sam will show IR26.

The [mygroups] token only works when the Assigned to User is populated with the actual group, and not when it is assigned to another Analyst that is in the same group. This results in the [mygroups] token for Glen showing only IR 26 and it will NOT show IR23 which is assigned to Sam, who is in the same group as Glen.

The [me] and [mygroups] tokens are not fully supported from the view builder GUI and require XML editing of the management pack that stores the view. See the example below of how to edit the XML.

Criteria AND OR

By default the criteria builder will join different attributes with AND. This is usually OK in most situations, but occasionally you would like to use an OR statement instead. Be careful with these and test them thoroughly as it is very easy to get more results than you expected.

To change the Criteria to OR, the easiest way is to build up the criteria in the View Builder with the default AND join. Then export the management pack that holds the view and edit the XML. In a simple example this is just a matter of changing the AND to an OR and then re-importing the management pack. See the example below of how to edit the XML for a more complex example.

SCSM Criteria AND OR

Column Display Names

When you add display columns to the view the column heading is the friendly name of the property. This is fine for most columns, but causes issues with any of the user attributes, where the column uses "Display Name" by default. Having three columns titles "Display Name" is not going to work for Analysts.

Again, we can fix this by exporting the management pack the holds the view and edit the XML directly. Find the display section and edit the string to a more appropriate value eg "Affected User", "Assigned User" etc. See the example below of how to edit the XML.

Default Column Order

Getting the correct order of the columns in the view can also require editing the XML or adding the columns to display in a particular order.

When the view is created or edited the order of columns will be in alphabetical order for that edit only.

If you want the following column order:

  • Id, Title, Support Group, Affected User, Assigned To User, Primary Owner, Created Date, Modified Date

  • Start by adding ID and Title when you create the view and then save. Then go back and edit the view and add Support Group, Affected User Display Name, Assigned to User Display Name and Primary Owner Display name and save again. Finally edit again to add Created date and Modified date.

  • Assigned to User, Affected User, Primary Owner display names will require editing in the XML file.

Or you can add all the columns at once and then edit the XML to move the default order of the columns around. This will probably not change for you as you would have checked the view with the original order and SCSM has saved this a view customization. Look for the Columns section in the XML which holds the mux:Column rows in the XML. Change the order of the rows to change the default column order.

SCSM View Column order in XML

Analyst View Customization's

When an analyst makes a change to a view and this can be as simple as clicking a column to sort, Service Manager saves this as a view customization for that analyst. When the analyst goes back into the view, the customization will be used and view will display as they left it last.

This can cause a bit of confusion when you as the admin are creating the view and change the column order. Generally it will not show the changed column order as it will be using your customization settings and not the default view settings.

Sort Order for ID Column

The Sort Order of the ID column is not numeric and instead by default will be treated as a string value. If you ID numbers are large enough, this might not be a problem. But if they are a low or change the number of digits used then you may notice this issue.

This can be fixed by editing the XML again. Find the ID column and add "ReturnValueAsBigInt" after the Id property and change the DataType to Int32.

<mux:Column Name=”Id” DisplayMemberBinding=”{Binding Path=Id}” Width=”100″ DisplayName=”Id.9108474bffe74ec98f268d6e5f7b948b” Property=”Id$ReturnValueAsBigInt$” DataType=”s:Int32″ />

Type Projections and View Performance

You probably want to use multiple properties from different relationships in the criteria and\or in the view columns. To combine these together SCSM uses Type Projections and it ships with a few default ones, for example the Incident (Advanced).

It is very tempting to use the Advanced type projection in your views, but this can impact SCSM performance, as the view then pulls all the data associated with the item regardless of whether it is displayed or used. Overuse of the Advanced type projection has the potential to make SCSM unresponsive.

Useful links on views and performance:

It is best to base the view on a type projection that only brings back the data you need and does not bring back extra data. This requires custom type projections that combine the most common relationships used for views. Xapity have done the hard work for you and you can download a comprehensive set of type projections from here:

If you need to create your own custom type projection, download the full PDF guide from the link at the bottom of the blog post and it will give details on how to build your own type projection

Create Views for Other Work Item Types under default Folders

It is possible to create views for other wort items under the default work item types eg a Release Request View under the Change Request folder in the console. The main consequence of this is that the context task menu on the right hand side is still going to show Change tasks rather that Release tasks.

Sometimes this is not a big deal and the benefit of having the two views next to each other is worth the small inconsistency.

View Folders

View Folders are useful to group views. The only issue comes with security roles as they are not a listed item. This means that you cannot hide a Folder - all analysts will see the folder even if they cannot see the contents of the folder. This may or may not be an issue, it is just something to keep in mind when planning a folder structure.

Full Example: Incident View My Incidents - Last 7 days

This will create an Incident view that shows the following:

  • IR Status equals

  • Active

  • OR Pending

  • Primary Owner = [me]

  • Assigned To = [me]

  • Assigned To = [mygroups]

  • OR Primary Owner = [mygroups]

  • Assigned To = [me]

  • Assigned To = [mygroups]

  • Created in the last 7 days = [now-7d]

This will require an OR statement between Primary Owner and Assigned To.

It will also have the following columns in this order:

ID | Title | Support Group | Affected User | Assigned To | Primary Owner | Created Date | Last Modified

SCSM View using Tokens

Step 1: Create blank Management Pack (MP)

Use the Service Manager Authoring tool to create a new blank management pack. This is just to give the Management Pack a friendly file name.

Using a new MP makes it easier to make the XML edits below.

Create SCSM Views Management Pack MP

Step 2: Consider what Type Projection you will use

To get the Incident details, Assigned To User, Affected User and Primary Owner you will need to use a combination class. Combination classes are based on Type Projections. Views that use the out of the box Incident (Advanced) type projection can cause performance issues as it pulls back all the relationships and data associated with the IR. It is better to use a targeted type projection that brings back only the data you need.

Combination Classes and Type Projections

Step 3: Create a new view

Give the View a meaningful name "Active Incidents: Last 7 days"

Change to Combination Classes and choose the appropriate class. This example will use Advanced as it is only being used in a lab environment.

And with the following criteria:

  • Assigned To Display Name| equals | [me]

  • Primary Owner Display Name | equals | [me]

  • Created Date | is greater than or equal to | Relative ticked | [now--7d]

  • Status | equals | Active

  • Status | equals | pending

Add in the columns to display. You could start with only three, ID (the second one in the list), Title and Assigned To Display Name and add more after editing the XML or you could add all them in at this point.

If you are going to use the IN expression with two tokens, you will not be able to edit the view after importing it back into SCSM (so in this case add all display columns now).

Step 4: Export the View Management Pack

Export the Management Pack that contains the view.

Step 5: Edit the Management Pack XML

In this step we will fix a three things:

1. Sort Order for ID property

By default the ID column is treated as a string value and this means that SR200 will show before SR56 as 2 becomes before 5. We can change this to sort as a number.

Find the ID Column info:

<mux:Column Name="Id" DisplayMemberBinding="{Binding Path=Id, Mode=OneWay}" Width="100" DisplayName="Id.3e240f03f5fc4f12b03b4c9a7864aaef" Property="Id" DataType="s:String" />

And then edit it. Change the data type from String to Int32. And add $ReturnValueAsBigInt$ to the Property Id.

New line looks like this:

<mux:Column Name="Id" DisplayMemberBinding="{Binding Path=Id, Mode=OneWay}" Width="100" DisplayName="Id.3e240f03f5fc4f12b03b4c9a7864aaef" Property="Id$ReturnValueAsBigInt$" DataType="s:Int32" />

SCSM View Sort Order for ID Column

2. Change the Assigned To Display Column heading

This will default to Display Name for any User property added to the view. Change this to something more meaningful for the analysts. As we only added one user field it is easy to just change the one Display Name that is in the XML.

If you add two user fields then search the XML file using the ElementID data to see which Display name is which user type. Using Primary Owner as an example in Notepad ++, highlight the DisplayName element on the mux:column row.

SCSM View Heading Display Name

Scroll down to the Language section and find the highlighted Element:

SCSM XML Language Section

Then change the Name tag to Primary Owner:

SCSM View XML Update Display Name

3. Edit the Token [me]

Find the expression area in the XML that contains the token [me].

We used the Assigned to and Primary Owner Property "DisplayName" to get the relationship items into the XML. Change DisplayName to Id (Edit the GenericProperty line}. ID is the property the token expects to see.

Then Change the <Value>[me]<\Value> to <Token>[me]>\Token>

Original XML

<SimpleExpression> <ValueExpressionLeft> <GenericProperty Path="$Context/Path[Relationship='CustomSystem_WorkItem_Library!System.WorkItemAssignedToUser']$">DisplayName</GenericProperty> </ValueExpressionLeft> <Operator>Equal</Operator> <ValueExpressionRight> <Value>[me]</Value> </ValueExpressionRight> </SimpleExpression>

XML after editing.

<SimpleExpression> <ValueExpressionLeft> <GenericProperty Path="$Context/Path[Relationship='CustomSystem_WorkItem_Library!System.WorkItemAssignedToUser']$">ID</GenericProperty> </ValueExpressionLeft> <Operator>Equal</Operator> <ValueExpressionRight> <Token>[me]</Token> </ValueExpressionRight> </SimpleExpression> </Expression>

Step 6: Save the XML and import to Service Manager

Save the XML and then import the Management Pack back into Service Manager. Restart the console and check the view to see if it has the data you expect.

If you get an error when you first go into the view. Try adding editing the view and adding an extra criteria: Add |Title Must not be empty

After saving the edit, hopefully you can go into the view without any errors. You can then edit the view and remove the extra Title criteria.

If you need to add more columns this might have the same effect as adding and removing the Title criteria.

Step 7: Optional: Add additional Display Columns

At this point you can still edit the view in the GUI - the criteria will be greyed out and cannot be changed, but you will be able to add more display columns.

If you do add display columns, export the management pack again before the next step.

Step 8: Add the [mygroups] Token

To add the [mygroups] token requires editing the XML again. In this example ae are after incidents that are assigned to [me] or [mygroups]. As this is an OR situation we can add the [mygroups] token in as a second line in the XML. AS we now have two tokens together we have to change the SimpleExpression to "In" and remove parts of the xml.

For [mygroups] to work the group CI object must be used in the property.

With the "In" expression the view cannot be edited in the GUI.

The starting point is:

SCSM Original XML File

Changes to make:

  • Add in the <Token>[mygroups]</Token> under the [me] token line.

  • Change SimpleExpression to In (and on the closing tag)

  • Delete the <ValueExpressionLeft> and the <Operator> lines (and the closing lines as well)

  • Change <ValueExpressionRight> to <Values> (and the closing tag)

Final XML:

SCSM View XML Tokens

Step 9: Save the XML and import to Service Manager

Save the XML and then import the Management Pack back into Service Manager. Restart the console and check the view to see if it has the data you expect.

SCSM View using Tokens

See these steps in action:

Watch more SCSM Admin Series videos here...

Xapity - Innovative Software for SCSM - Discover our Products

#Tips #SCSM #Customizations

2,007 views0 comments

Recent Posts

See All
bottom of page