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….
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…
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.
If User A cancels out and never actually submits incident 219 and User B does submit incident 220 then you will the following incidents:
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:
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.
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.
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?
I dont know why IRs increase by 2 each time. Probably a bug. I've never even noticed that. :)
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.
So, there is no way to correct this increasement by two on the ID´s?