MDA dropdown values show GSID when exported

@Wayne yes that’s an option, though I really don’t want to create a duplicate field just to work around this issue.

Agreed, was adding on to the annoyance and extra work/resources that is needed to work with this lack of a feature. 

Adding to the chorus of voices here, the ability to export picklist values as they are labeled quickly and at scale (without workarounds of extra tables, fields, rules to manipulate extra tables/fields, CASE statements, etc.) would be a big win.

How do transition this need beyond a “Question” thread to become an idea we can upvote?

@matthew_lind  - is this still an issue for you ? 

@Azad   in a larger sense, yes.  This isn’t just about getting the extra field in an export.  It’s about the bigger picture.

• This caused our Snowflake team to do some hefty data management acrobatics on import because the native picklist/multipicklist field only exports the GSID.  
• This prevents us from being able to leverage the data in external API action in various ways because the field natively only exports the GSID.
• This prevents us from being able to do field comparisons (i.e. between Salesforce and GS) because one side natively contains a GSID, without making custom case expression fields that limit you to 10 cases.
• This makes it very difficult to use Rule/Program execution logs.

The workaround where Gainsight exports an extra field containing the label should be considered a workaround only.  When would an admin ever use the GSID value of a picklist/multipicklist field over the label (especially when we have no way of looking up the GSID of each value)?

This has become a bigger issue for us in NXT where admins have greater ability to create custom fields and so this issue will only grow, not diminish.  Admins should not be required to contortion complex and costly solutions to work around such a gap. 

@heather_hansen @bradley @brad_tippetts @mindym @mindy @travis_floyd 

I ran into this yesterday and had to rework a whole program in JO to accommodate. I already have the flag turned on mentioned in the answer.  As Jeff mentions, I needed to do a merge on with an SFDC field and a GS field, and had to instead use a case expression first instead of just a straight forward merge. The current config causes a lot of extra time and work, and the fact that you can’t find the GSIDs anywhere exacerbates the problem.

@Azad - The pain remains.

Though there are some workarounds, they are heavy and do not scale. I couldn’t illustrate this myself better than the 2 previous comments with examples from @darkknight and @heather_hansen 

I would also add to this, which is something I’ve mentioned before, that there is an underlying issue with data types in Gainsight. Gainsight seems to have data types that are displayed to admins, and further subtypes that impact system functionality but are not exposed to admins  -  this is also very evident when working with Salesforce data. For example, a Formula field and a String field both show up as String fields in Gainsight, but the operations you can perform on those two fields are very different.

Data types also change what field type they are displayed as depending on where you are in Gainsight - follow a URL data type field from Data Management into a Rule, and you’ll see it shows up as a Text/String field.

At the recent rollout of the Associated Records in Timeline, the feature was published with text fields in the configuration but displaying ID values when used in Timeline. Clearly, those text fields were ID fields.

I’m sure it won’t be technically easy to change how picklists, or items that store values as IDs and then have a separate labelling system, are exposed to users - But the point is, data types need to be consistent and therefor predictable in their behavior across the system - if that means exposing more data types to admins then that’s a good thing because we can predict rather than guess.

They also need to be useful - exposing the IDs is useful for troubleshooting and disambiguation, but human readable text is important for end users and configuration set up where you need to know what values mean when you’re setting up connections.

@rakesh @Azad Any thoughts on following up with this? I realize it’s marked as solved, but not sure that’s an accurate reflection of the conversation :)

Hi All,

I understand that what we shipped is not enough. Both Bradleys and Jeff’s post do confirm that. The reason all systems in Gainsight work on GSID’s than Names is because of the design of dropdown lists. 

What we are working on now is to seamlessly give an option to specify if you want a picklist (id) or a string (label) when you fetch the data itself. We are targeting to release this in Data Designer in short term (Mostly this year) and then this would follow in Rules.