@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

@bradley Thanks for the feedback. Will keep it in consideration.

Thanks - I’m sure it isn’t an easy fix but it’s a very important one especially as talks of more bi-directional syncing between GS and SF are under way.

@anirbandutta can we get some new thoughts on this?

@bradley , @gunjanm , we admit that we are limited by what is possible to be achieved here technically, and wouldn't be able to include this usecase. It’s a technical blocker.

Does that mean stripping out unsupported characters that cause failures is not being considered either? We are just stuck with the inability to use an extremely common and generally supported character in other platforms?

Added in my use case as well. We use a picklist/dropdown to map the Billing Country at the account level. If you look at ISO 3166 and 3166-1 there are countries with a single quote. EG: Côte d'Ivoire .

This is becoming more and more of an issue for us. Can wse revisit this please?

@revathimenon Can we get some  on this? This is an old request with sort of a vague “not something we can do about it” handwave but this is a vexing issue that really limits interoperability between Gainsight and SFDC. @pgeorge any insight?

We have had this cause us a number of issues. PLEASE can we get this fixed so special characters can be imported. My organization is European and the number of special characters we have is very high to support the different languages we operate in.