I had a task recently to reduce down the number of statuses on an entity, basically taking it down from 20 to 10.
As Adam pointed out in the comments, I am referring to Status Reason = statuscode. For each Status you can have a number of Status Reasons e.g. Active status can have lots of status reasons such as New, Modified etc.
There isn’t any dependency checks in CRM, you can delete statuses even if there are records with that status.
The consultant was suggesting we deactivate the status reason, erm no, you can’t do this either. You could change the status reason to
DO NOT USE – Old Status
This is ok and offers you an easy way to move these options later and stopping (although not always) users from selecting the soon to be deleted status reasons. Personally I don’t really like it because it looks messy and seems like it may lead to more problems later.
Mapping Statuses
If you are going to remove the status reasons then you need to map the old status reason to the new status reasons BEFORE you delete the status reasons. if you don’t then the user will open up the record with the deleted status reason, it will try to look up the int for the status reason, can’t find and then show the default status reason for that status.
What happened was I forgot to map the status reasons across and then I ended up with lots of status reasons which no longer existed. A curious thing happens, the int value is still held in the database. When you open a record which has the old status reasons, on the onload of the form it will change to the default optionset status reason but this will only write back if you save the record.
So lets say I have four statuses
New
Waiting for user
User replied
Resolved
They get rid of one so we are left with three statuses
New
With User (renamed Waiting for user)
Resolved
If you forgot to set the values of the old status reasons to new ones e.g. all the records with a user replied status reason and set it to With User then these records will have the int value for the previous optionset.
The renamed status reason is fine because the int value is the same, when you go to the forms you will see the renamed status reason
How to Fix it
To fix the problem, I did an SQL query on the database table holding the records. I selected all the records and got the name and statuscode value and only for rows with the old optionset value. I then did an advanced find in CRM and selected all the records which didn’t have a status reason for the three left.
I now had the records with dodgy status reasons. I exported the list and ticked the re-import check-box. I then sorted the rows so they were the same to make sure I had the right records. I then updated the status reason with the correct option and re imported.
The morale of the story is be careful when you are deleting status reasons and make sure you have mapped them before you delete any statuses.
Hosk's Dynamic Blog 
I think you mean Status Reason (=statuscode), not Status (which you can’t modify). And everything you have said is true of any option set – it keeps the int values in the database.
This gets even worse if you get rid of a load of options, lets says you delete the option set item “Banana” which had integer value 4. No records change in the DB. Your colleague later adds a new option set item “Apple”, using the next available number: 4. Now all those records when opened will have the value “Apple” (just as if you had renamed the option set item).
To help avoid this, always add to the description property on the option set any details like this, such as “do not use values less than 5 because…”
Also note that if you make the default have no value, you are less likely to end up with incorrect data, just blank entries (usually less bad). Of course, you can’t do this for Status Reason, only for other option set fields).
Extra tip: if you have two local option sets on two entities and they are mapped from one (parent=source) to the other (child=target), any integer option that does not exist in the target is *dropped* during mapping. You don’t end up with random integer values in the database that have never had a label associated with them. Of course you should make sure that mappings line up, but at least if they don’t you won’t see weird data later. (PS: I think this is described incorrectly in the old 80294 CRM 2011 customisation course).
LikeLike
Thanks for the comment Adam, yes status reason and not status.
I hadn’t considered what would happen if the status reasons where recreated with different values. Actually this would have possibly been an easier way to do it, I could have create the status reasons again, did an advanced find and bulk edit.
as always you are adding a bit of extra chocolate sauce to the main pudding of my blog post
LikeLike
Can you provide which tables you used to qry the status records? I can’t find the table.
LikeLike