Hi There,
Currently, when you create a dropdown-list item with a single quote, the following message pops-up.
Although one understands the validation but this becomes a problem when you have mapped this field in SFDC connector sync job and in SFDC picklist value contains single quotes etc. So are there any thoughts to allow dropdown value with single quotes because in SFDC picklist, we can have values with single or double quotes.
For now the only work-around is to have a String type in MDA mapped to such picklist.
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?
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 !
Great idea@shiv_kumar_katiyar !
@All, please leave your vote here!
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?
edit:@sai_ram just bubbling this to the top
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.
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?