Hello - I was creating a new global option value set and CRM prompted me with a message stating that the value I used for an item did not match the configured option value prefix of 10,000.
Basically, the option set is for Level and the values are 1-10. It makes more sense to me to use a value of 1 for an option of 1. What type of numbering convention do you normally use for this?
*This post is locked for comments
@Guido - Thanks for your patience. I think I'm getting a better understanding. So say I'm a PM in charge of a CRM app. We have a significant amount of fixes and small features that need to be developed and delivered. I decide to outsource a chunk of this work to ConsultingFirmX.
As part of this work arrangement, I could get ConsultingFirmX to publish all of its changes through its own publisher named CFXPublisher. By configuring this publisher with an option value prefix of "123", all option set values added by CFX would be immediately identifiable.
Is this a valid scenario demonstrating the benefit of the option value prefix? If so then what steps could I take to help ensure that CFX always publishes its changes with CFXPublisher instead of DefaultPublisher? What are some examples of some other benefits that can be gained from a specialized publisher?
1 downside would be dealing with a set of optionset values with an inconsistent pattern. For example:
1, 2, 3, 5554, 10005
However, I can also see how this would provide some clarity. Thanks.
"differentiate a custom value from an OOB value"
Very good point
"As the administrator of the CRM, if the company buy a third party solution, the administrator can ask them to use a unique publisher prefix and a unique optionset prefix (unique for the company CRM environment)"
Sorry - I'm not quite clear on this point. Are you saying that if I contracted CompanyX to build me a CRM case management system then I might want to ask them to use a special optionset prefix so it would be clear which optionset values were added by CompanyX. Then when the app was turned over to my maintenance programmers I would change the optionset prefix to know which optionset values were added by my internal team?
"If you use a publisher you can choose the prefix, is important if you export your solution in environments where other solutions are installed, to differentiate your optionset from other optionset."
Hi Guido, if the benefit of the option set prefix is to differentiate a solution optionset from optionsets in other solutions in the same environment and every solution is using the same default option set prefix then I don't see how an option set prefix would help with differentiation.
Also, it seems like the domains of different solutions should be well defined and isolated without any ambiguity about which objects belong to which solution. Why would this issue exist with option sets between solutions?
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,280
Super User 2024 Season 2
#2
Martin Dráb
230,214
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (