What happened to DeletionStateCode?

DeletionStateCode is no longer in CRM 2011. The following post provides a good history and reasons for deleting the DeletionStateCode field.

Obviously the implication of removing this field is that now when a delete operation is performed it is a lot more permanent. You can no longer quickly go behind the scenes and run a script to retrieve the deleted entry (or entries as cascading rules might take effect). Not that you ever should have taken the action of deleting lightly, but now you will want to be that much more sure when you are faced with the "Are you sure you want to delete the [entity], including all records under the [entity]" prompt...

If you have auditing enabled for the entity in question, you will be able to see the entity with all its attributes along with any audited sub-entities and all their attributes so information in this case is not lost and you could painstakingly recreate the entity from this log. However there's a big caveat in the above i.e. the assumption that the entity in question and all sub-entities are being audited (which is quite a big assumption especially on the sub entities which can vary per delete operation). The image below shows the Audit Summary View of a deleted account entity along with the child contact entity - as illustrated, the details could be reconstructed.

If the entity is not being audited then the only way to retrieve the deleted record(s) would be via a database restore operation and some SQL queries to retrieve the data (assuming you didn't want to restore the entire database on top of the production version).

In spite of this, I view the removal of the DeletionStateCode in a positive light. The question arises - how many layers of protection is required to prevent the user from deleting something that should not be deleted? Here is what we already have:

• Warning - The "Are you sure" prompt making users think twice before confirming the action they wish to perform
• Record Status - We already have the active vs. deactivated record status. A deactivated record is in a sense a deleted record i.e. it is removed from all active views. When in doubt users should deactivate rather than delete.
• Permissions - The availability of the delete action is controlled via permissions. Best practice recommendations are generally not to provide end users with delete permissions for sensitive data. 
• Audit - As mentioned above, the audit tool provides another line of defense for something that has already happened.

The Audit feature is new in CRM 2011 and perhaps this additional measure is what pushed Microsoft over the edge in terms of removing the DeletionStateCode. Whatever the underlying reasons might be - the benefits of the removing this field (as mentioned in the referenced post above) far outweigh the pitfalls.

As a last point, the impact to reports in a CRM deployment should be low. That is because CRM reports are meant to adhere to the CRM SDK, and such reports referenced the Filtered Views which anyway did not have this field in their definitions. If you are finding that your reports are failing as a result of this change, then that might be an indicator that your reports were not written adhering to the SDK standard which is something you may want to look into...

You must enter a number between 200,000 and 2,147,483,646

When entering a picklist value you may be presented with this error message:

This is a pretty well known issue and anyone who has been working with CRM for even a short while is likely to have encountered it. The solution is fortunately equally simple and presented at the bottom of this post.

With the advent of CRM 4.0, it was possible to not only overwrite a picklist Label but also the associated picklist Value. This gave much needed configuration options to the person configuring CRM but it also introduced a risk in that a user could change a picklist value to overwrite a value that is referenced in the database thereby losing that reference. And indeed if you try to do so you will be presented with the following warning:

But for whatever reason Microsoft decided to give the customizers of Microsoft CRM the option for configuration in this case along with the responsibility for taking such a design decision. This is a good thing. 

The caveat is that the above works for custom picklist attributes that you might create. For some reason when it comes to out of the box attributes, Microsoft suddenly seems to have gotten cold feet. Because in this case you are not able to create a new picklist value with a Value of less than 200000. So here we have a case where Microsoft giveth and Microsoft taketh away...

I am not entirely sure what the rational was for such a limitation but I can only surmise that it was guided by the following thinking:

• Protect against over-writing existing system values which could be used by the application (now or in the future)
• Have a clear differentiation between values that came with the out of the box configuration and values configured during a customer deployment

You may ask - what's the difference? The picklist Value is anyway completely behind the scenes and therefore what do I care if it's value is 15 or 1500? As long as I see the correct Label that's all that should matter. And for the most part and likely in most cases this thought process would be correct.

But consider the case where you have an integration between your CRM deployment and another internal or 3rd party application. If you are integrating the picklist value between a similar drop down/picklist in the other application wouldn't it be easier and more straight forward and make long term maintenance that much simpler if the numbers were the same? Of course it's not difficult to create a cross reference to map these values during integration but that takes the solution just a little further from "simple" than it needs to be. And therein lies the crux of the issue of limiting the configuration option and not entrusting the responsibility of such a design decision to the system customizer.

I for one would like to see additional optional attributes on the picklist attributes (or Option Set as referred to in CRM 2011) which would give additional options for integration mapping purposes which hopefully Microsoft will introduce in the not too distant future.

Happily in CRM 2011, it seems that Microsoft realized the limitations that they had imposed on those who really want additional configuration options and no longer imposed this via the front end.... or perhaps they realized that those who wanted to have this kind of freedom were not deterred by the front end limitation and instead took the back door configuration option as described here (for CRM 4.0):

1. Export the entity in question. For example to export accounts navigate to Customizations | Export Customization | Account | Export Selected Customization
2. Search for the attribute in question (e.g. accountclassification code)
3. Manually add a new picklist option as shown below
4. Import the entity and publish