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):
- Export the entity in question. For example to export accounts navigate to Customizations | Export Customization | Account | Export Selected Customization
- Search for the attribute in question (e.g. accountclassification code)
- Manually add a new picklist option as shown below
- Import the entity and publish
No comments:
Post a Comment