Dropdown list item with single quote

@shiv_kumar_katiyar 

Thank you for letting us know.

I will look into this and see if we can revisit the validations we have set for Dropdown items.

Hi @shiv_kumar_katiyar 

We currently use Single, Double quote and Semicolon as separator characters and hence cannot be included into the special characters involved.

Is it possible to rename the picklist item name from SFDC and do a sync?

@shiv_kumar_katiyar did u get a chance to view the comments posted by @pgeorge 

thanks @pgeorge for taking a look! Client was already aware of that, so I suggested him to take the rule approach-

create the value without quotes inside Dropdown and via rule you can actually map it and populate. Something like below-

this is becoming challenging with other integration as well -

Great idea @shiv_kumar_katiyar ! 

@sai_ram - can we change this to a product idea?

@jean.nairon changed to idea.

@All, please leave your vote here!

@sai_ram I realize this appears to be a dead idea, but I feel it is my duty to reiterate how big of a problem this is and why mapping a dropdown to a string picklist is not an acceptable workaround.

Why mapping a Picklist>String data type is not a workaround:

The obvious problem is that they are two different data types. In case I need to explain why that’s a problem consider this: If you have a dashboard looking at MDA and SFDC objects, you are going to have to use one filter for your MDA objects and one for your SFDC objects. Terrible end-user experience not to mention it looks bad.

Why dropping any ‘, ‘’ etc., is not a workaround:

If you are trying to do any type of equivalency match between data, GS does not seem to trim the data and exclude characters it doesn’t support, or even give you that option. So even if you used a rule to map Children’s to Children and think it will work, try using a Global filter with your new MDA field with both SFDC and MDA objects. You’ll get this error message.

The “solution” is to go back to your SFDC instance and change the values to remove any punctuation. This, quite frankly, is in most cases not a viable alternative nor should it be. People are very tied to their SFDC deployments and you may have to deal with multiple levels to get a change approved, and then wait for it to happen.

I see two viable solutions to this. The first would be just to allow additional characters. Since you know by now Salesforce is used quite a bit with GS, characters should be supported at parity with what Salesforce allows. This would result in the best user experience and show that the platform has maturity. Another alternative would be to strip non-supported values before doing equivalency checks, so that you don’t punish users for having used Salesforce first.

I don’t know if I’m the only one who feels strongly about this, but it seems like this should have not been an issue a couple of years ago. @gunjanm or @darkknight have any thoughts on this? Am I off base or would getting this resolved be a huge boon for customers and the platform?

@bradley I think you’ve put this together very nicely. This is definitely one of those admin nuances that seems small and petty at first but has immense value and should be prioritized and considered by the team. 

@gunjanm Thanks for the sanity check. It seems pretty fundamental but I also realize I can be a bit biased on what I think the impact is :)

edit: @sai_ram just bubbling this to the top