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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.