FAQ: Why Don’t Work Item IDs Increment Uniformly?

FAQ: Why Don’t Work Item IDs Increment Uniformly?

  • Comments 6
  • Likes

Let’s say you create an incident – it has an ID of IR210:


2 minutes later you create another incident and it has an ID of IR262:


You know that there couldn’t possibly have been 51 incidents created in the last 2 minutes because you are the only person working late at night tonight.  Ever seen this happen before?  What is going on??

Here is how the work item ID field works….

  • First of all, it is important to know that the incident ID is an inherited property from the Work Item class.  All of the work item classes like change request, problem, activity (and in SCSM 2012 – release record, service request) all inherit this property. 
  • The ID property is the key property for all of the work item classes meaning that it must be unique for each work item.  It is not possible to have two incident with ID = IR210.  It is also not possible to even have a CR and an incident with the same ID.
  • The ID property is an auto-incrementing property.  It is formatted as <configuraable prefix>{0} where the {0} is replaced with an automatically incrementing integer and the <configurable prefix> is configurable for each work item class.  You can even have no prefix value if you want to.

What this means is that the work item ID increments for every work item that is created regardless of what class of work item is being created.  Imagine this scenario…

  1. Incident 210 is created.
  2. Change request is created – it gets work item ID 211.
  3. The change request contains 5 activity work items – those are IDs 212, 213, 214, 215, 216.
  4. Another incident is created – its ID will be 217.

It is also important to know that if a work item form is opened the work item ID is “allocated” for the creation of that work item – even if the work item is not actually created.  Thus this scenario is possible.

  1. Incident 218 is created.
  2. A user (User A) opens a incident form to create a new incident.  ID 219 is allocated.
  3. A different user (User B) opens an incident form to create a new incident.  ID 220 is allocated.

If User A cancels out and never actually submits incident 219 and User B does submit incident 220 then you will the following incidents:

  • Incident 218
  • Incident 220

There will never be a incident 219.  Or any work item with ID = 219.

Why did we do it this way – having a work item ID shared across all work items?

Having a common work item ID makes it easier to find the work item that somebody is talking about because you don’t need to clarify the work item class.  Imagine this dialog:

Bob: “Hey look up number 1234”

Tom: “Are you talking about an incident or a problem?”

Tom doesn’t need clarification on the work item class because the ID is unique across all work item types.  He can just type it into the search bar and get the work item immediately.

It looks a little strange to see non-sequentially ordered work item IDs at first, but after awhile in a production system with tens of thousands of incidents in it, you wont even notice any more.

Why do we allocate work item IDs even if they are not used?

This was an interesting problem actually.  These were the requirements from customers:

  1. Automatically increment the number.
  2. Display the number in the incident form before the work item is actually created so that the analyst can refer to the number when talking to the customer.
  3. Keep the sequence of numbers in order chronologically

If we allocated the numbers at the time the the incident was saved we would  have a perfect sequence (assuming other work items were not created in the meantime) but it would not be possible to display the ID when the user first opens the form (violating requirement #2).

If we allocate the number at the time the form is shown then we satisfy all three requirements, but we don’t end up with a perfect sequence.  Since we are not going to end up with a perfect sequence due to the work item ID being shared across all work item types anyway, we felt this was less important.

If we went back and used numbers which will allocated but never used we would violate requirement #3.

We discussed this design with quite a few customers and given all the tradeoffs this seemed to meet the most important requirements.

It’s just a little odd if you don’t know the story behind it.  I hope this helps clear it up.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Thanks, Travis.

    That helps clear up some of my questions that I've had since implementing SCSM.  However, it still doesn't explain why we can't sort based on the ID number.  

    When I sort an Incident view based on ID number, using your examples above, I see IR210, IR2100, IR2101, IR211, IR2110, etc.  I would much prefer to see IR210, IR217, IR218, IR220 which makes a lot more sense to me.

    Thanks again for all the info you provide in the blog.  I've found it very, very helpful in administering and configuring SCSM.

    Chuck Roy

  • Chuck

    Since the ID is a combination of letters (the prefix) and numbers, it's stored as a string and therefor sorted as alphabetic.


    How come IRs are created with an increase of the ID by 2? IR10, IR12, IR14 and so on?

  • @Anders -

    I dont know why IRs increase by 2 each time.  Probably a bug.  I've never even noticed that. :)

    @Chuck -

    I've never tried it but I wonder what would happen if you didnt have a prefix so the IDs were just numbers...  I think it would still string sort.  But then I was looking at this tool that Anton created:


    He has a checkbox thing there where it looks like he can tell a column to sort as a number.  Not sure if by using that in combination with not having a prefix you could get a column sorted as a number or not.  Worth a try though.  

  • Chuck, since the ID's are in chronological order you could edit the view to add "Created Date" and sort on that instead.

    Also, as a little piece of trivia, notice that the "All Change Requests" and "All Incidents" views _do_ sort on the ID as you're expecting..it's a little trick in the view binding that Microsoft uses. The property they bind to is a modified ID property returned as an integer: Property="Id$ReturnValueAsBigInt$"


    Hopefully that's not a trade secret =)

  • Thanks Travis! Just FYI, we also see the same thing that Anders sees.  Our ticket IDs always skip a number (ie. IR40 to IR42; or with CRs, CR10 with MA11, MA12; then skips to CR14 with MA15, MA16). Not a big deal, just FYI.

  • Hi Travis.

    So, there is no way to correct this increasement by two on the ID´s?