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…
- Incident 210 is created.
- Change request is created – it gets work item ID 211.
- The change request contains 5 activity work items – those are IDs 212, 213, 214, 215, 216.
- 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.
- Incident 218 is created.
- A user (User A) opens a incident form to create a new incident. ID 219 is allocated.
- 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:
- Automatically increment the number.
- 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.
- 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.