+7When viewing participants in a JO, picklist GSIDs are shown, when those picklists are mapped as custom fields. Those should be the human-readable picklist value. I don’t believe an Object exists in NXT that allows you to look up the GSIDs of picklist values.
We have been seeing this recently as well and it appears to be new behavior as of a recent release/update… Our Boolean fields also switched from uppercase TRUE/FALSE to lowercase true/false. (Shown are some old participants and some recently added)
+4This was true with MDA picklists in SFDC edition also (and affects rules as well,) but it is an even bigger one in NXT where we can create custom fields on core objects.
I’ve raised this a few times with Product and walked away with the understanding that it wasn’t a priority because it would require a lot of effort to solve and that we could just use a Case Expression to translate.
That’s not a good solution, especially if you have numerous picklist options or (heaven forbid) multi-picklist. And to your point, you would have to know the GSID of the values...which is not easy to figure out especially if there are values no one has selected before.
+4For the JO use case, this is already solved and the relevant field should be mapped as a Custom Field with data type Dropdown, instead of String
Thanks to
+4I wouldn’t call this solved. There are still plenty of areas in the product where this is a problem, including relationship associated object mapping.
+3
+12Also, multi select pick lists are still an issue and they’re a big one at that.
+2I changed that.
Getting some PM eyes on this thread.
If you ever had a profile with us, there's no need to create another one.
Don't worry if your email address has since changed, or you can't remember your login, just let us know at community@gainsight.com and we'll help you get started from where you left.
Else, please continue with the registration below.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
