CI Assemblies/Configurations – How To Use Them – Part 1

CI Assemblies, or Configurations as they used to be called prior to Service Desk Express 9.6, are the basis for grouping Configuration Items, or Inventory Items prior to 9.6, together by location. What I thought I would write about in this post are my views on best practice for using them and some of the tricks/tips you might want to employ/watch out for in your own organisation.

A little imagination required…

I am going to try and explain the use of CI Assemblies through three, hopefully relevant, examples relating to a single, hopefully relevant, organisation. So for the purposes of this post, imagine an organisation spread over a number of sites, with assets and users in a variety of different buildings and rooms. Imagine that this organisation has a mix of laptop and desktop based users, using shared printing facilities and, to make it a bit more complex, using roaming profiles and hot desks. Finally, imagine that this organisation wants to be able to bill departments based on the assets assigned to them/their users.

So how could you implement this?

The first thing to understand is the database structure relating to CI Assemblies:

As you can see from the figure above, Configuration Items are linked to CI Assemblies on a one to many relationship such that a single configuration item can only be linked to a single CI Assembly but a single CI Assembly can have many configuration items assigned to it. Slightly harder to understand, a single CI Assembly can be linked to multiple clients AND a single client can have multiple CI Assemblies i.e. a many to many relationship. This is what provides us the flexibility to handle the example above but at the same time it provides an added level of complexity that needs to be very carefully handled, particularly when it comes to writing reports. More on that later.

So back to the question – how could you implement this?


The first thing I would suggest you do is add one or more modules to provide a definitive list of locations. Out of the box Service Desk Express doesn’t understand the concept of sites using CI Assemblies to manage locations. The building and room fields in the database are free text which can lead to data inaccuracies as a result of misspelled or abbreviated building names. I would suggest you build three new modules for Sites, Buildings and Locations as per the schema below:

So now each CI Assembly can/shall have a definitive location.

It is critical that your organisation agrees on a naming convention for CI Assemblies. I would suggest that you have a different naming convention based on the type of CI Assembly for reasons that will become apparent.

Now you can create a single CI Assembly for each desk in each location using the following naming convention for the CI Assembly ID: SSS_BBB_LLL_DDD where:

  • SSS is a three letter site code
  • BBB is a three letter building code
  • LLL is a three letter location code and
  • DDD is a three letter desk code.

This sounds like a lot of work and it is. The good news is that generally this information is relatively static data so once entered/imported the hard work is done.

Next we can assign all the fixed assets – desktop PCs, monitors, docking stations to these locations. For those users that are fixed to a given desktop PC I would then assign that CI Assembly to that Client. Hot Desks are frequently billed by department so I would link the hot desk CI Assemblies to the department manager.

OK, so that sorts out the hot desks and fixed desks. What about the mobile users.

Create a single CI Assembly for each user with a CI Assembly ID equal to their Client ID as a naming convention. Into this CI Assembly would go each user’s laptop, mobile phone, PDA etc. and potentially, depending on how you manage software licenses, each user’s software licenses. When a user logs a ticket with the Service Desk, the Service Desk is able to check where they are say and consequently link that CI Assembly ID to that user giving them a pick list of assets based at that location. That will sort out the mobile users.

So why does the system need to allow multiple users to own/use a single CI Assembly? Amongst other reasons – printers! We need to create a CI Assembly for each shared networked printer using an appropriate¬† naming convention (I’ll leave this one up to you). Assign the relevant configuration item (aka the printer) to it and then link each user that uses that printer to it. WHY????

Think for a moment about the Service Desk Agent – takes a call from Joe/Jane Public and is now able to say, “What is the issue?” and now has an appropriate configuration item to link to EASILY pretty much no matter what the answer is. This results in amazing data for analysis and take problem and change management to an exciting new level.

In the next post in this series I will look at some of the ways (read business rules etc.) that can be included to reduce the manual burden associated with the solution I have proposed above. Additionally, we will look at some of the issues/techniques for reporting on this solution.

As always, hope this has proved informative. Any comments, positive or negative always welcome. Thanks for reading.

Email Conversation and Notifications

I can’t imagine any Service Desk Express implementation that doesn’t involve a business rule that sends an email to a client when a ticket is logged in their name and I remember back in 2003 my first ever business rule did exactly that. The thing was that I was also asked to create an Incident Detail that recorded the fact that the email had been sent along with the content of that email.

So what’s the point. Roll forward five years and we now have Service Desk Express complete with Email Conversation. Email Conversation out of the box, allows support staff to click a button from inside a ticket and send an email using a web based interface. Out of the box, the fact that the email has been sent is recorded as an Incident Detail complete with the content. Out of the box, if a client replies to said email, an Incident Detail is automatically created containing the content of the reply and an email is sent to the support staff the call is assigned to. The point is – you can programmatically create an Email Conversation record via a business rule and consequently you automatically get all this functionality – out of the box.

If you want to use Email Conversation programmatically then you need to create a new Email Conversation form through Form Customisation. The important fields to include on this new form are:

  • Module # – This field determines which module the email conversation refers to e.g. Incident, Work Order, Purchase Request etc. It is important to understand that you need to use the Sequence number of the module concerned NOT the module name. In the case of Incidents, the Sequence number is 24. You can find out the Sequence number for other modules using:
  • Record # – This field determines which record in the above module this email conversation is linked to. So in our case this will be linked to the Incident # of the incident raised.

An example new email conversation form is shown below:

Once you have done that you can go ahead and create your very simple business rule.

Shameless Plug
If you haven’t downloaded a copy of Nashco’s Business Rule Print Preview do so. You can get it from here. It is a very cool little executable that adds additional functionality to the Business Rules Manager window and Business Rule Customisation window allowing for the printing/documentation of business rules. It also works with Client-Side Business Rules too.

The simple business rule required is shown below thanks to the above Nashco Business Rule Print Preview application:

With a rule like this replacing you standard notifications, the client essentially ends up with the same email but you automatically get all the added functionality mentioned above for free.

As always, hope this helps. Keep your feedback coming (positive or negative) – I really value it.