Solved

MDA dropdown values show GSID when exported


Userlevel 5
Badge +3
We've noticed that when including an MDA dropdown list field in a report, we get the GSID values when we export said report, versus the value's display name.



We show the display name in the report itself, but as soon as it's exported, we get the GSID that we are unable to decode and understand the text value.
icon

Best answer by rakesh 24 December 2020, 11:02

View original

39 replies

Userlevel 7
Badge +2

I know there hasn’t been activity on this post in a year and it’s marked “Solved” for some reason, but I want to point out that this picklist GSID thing is still a major problem. I’m building our Relationship architecture and was hoping to use a simple picklist on the MDA relationship object to associate our data to a matching picklist in SFDC. It seems that this is simply not an option because Gainsight’s picklists don’t play nice with Salesforce. Instead of just passing through the text field of the picklist value, Gainsight passes through the GSID, which of course Salesforce’s picklist doesn’t recognize. 

 

I’m now forced to create a second field on our Relationship object just to hold the string value of that picklist I created because that’s the only way I can get my associated mapping to work apparently. This is frankly absurd.

Userlevel 7
Badge +2

This is a pretty major issue in my opinion. I see that I can ask support for including the name too, which I will do. But the issue still remains that we can’t use MDA picklists in string formulas at all in the Rules Engine - i.e. you can’t do a LEFT formula, you can’t convert them as a string using Case Expressions, etc.

 

This is especially frustrating considering you can do all of the above with SFDC picklists. Why would our MDA picklists not function the same way?

Userlevel 6
Badge +5

@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 @bradleymcg @brad_tippetts @mindym @mindy @travis_floyd 

 

 

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.

Userlevel 6
Badge

I see multiple product areas being discussed here: 

  1. Reporting → When you export a report which has a dropdown value we are currently showing labels only, not GSID’s. If anyone is getting GSID’s in any scenarios, I recommend raising a ticket.
  2. Rules S3 export → We have a backend flag which when changed will also send the label in addition to the GSID. This should be on for newer customers by default, for our older customers who might have already created some data flows using GSID’s we could not automatically do this change for all customers. Please reach out to support if you want this for your org

Hope this covers everything

Userlevel 3

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

Userlevel 2
Badge +1

Any resolution on this.  We just set up an S3 export for our data team and all the picklist data came through as GSIDs. 

Userlevel 7
Badge +8

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.

Userlevel 7
Badge +3

@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 

Userlevel 6
Badge +5

@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 :)

Userlevel 2

I too have the same issue, we are trying to export data to S3 and all the picklist data came through as GSIDs. 

Userlevel 1
Badge

Just going to chime in here with my scenario. I have a rule I’m working on that merges data from SFDC with Relationship data in Gainsight. Both objects have picklists with overlapping values, and some that fall into what I would call buckets.

At the end of the rule I want to merge the two datasets on a combination of the Account ID and the value of the picklist “bucket”. But I’m unable to do so, because it always tries to join the text value from SFDC to the GSID of the value in MDA. 

Unless I create a complex case statement (which already a has a hard limit), I can’t perform this merge. The only other thing I can think of is to export the data to S3 first, just so I can have the solution mentioned above provide the labels Then have another rule actually run the merge. This is so much unnecessary work just to merge on the value of a picklist.

I have tried other things, like using a string formula to pull a substring, which only pulls a substring of the GSID. I have tried creating a formula field on the Relationship, but I can’t draw from the dropdown field with the formula creator. I’m at a loss for now, unless I want to implement a convoluted workaround.

I would think we would need the option to pull the GSID or the Label into the rules engine as well. Not just data designer.

@rakesh 

Userlevel 6
Badge

@jordan_cook 

We are working on a way to get all the capabilities in Data Designer into Rules Engine

Userlevel 7
Badge +2

@Nalin and @Justin Bills did you get a chance to see the comments here?

Userlevel 7
Badge +2

@rakesh The ability to leverage the actual Picklist values throughout GS is becoming more crucial.  I just added this question in another post.

Userlevel 7
Badge +3

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?

Userlevel 7
Badge +2

Here’s another scenario where storing the picklist values as GSIDs leads to frustration 

 

Userlevel 7
Badge +2

@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 @bradleymcg @brad_tippetts @mindym @mindy @travis_floyd 

Userlevel 1
Badge
+1 to this.  I've been looking for a solution to this problem when exporting to S3 via Bionic rule - only the GSIDs for MDA dropdown values are exported, not the actual value. (Same if you transform the data in any way - still only GSIDs are exported.)  Also the GSID isn't displayed in the Category (dropdown) UI so you have no way to marry the values to the correct account fields post-export. 
Userlevel 5
Badge
Hey Jeevan- Just came across a customer for whom the export from report builder still shows GSID's rather than the value/label of the dropdown list. Could you confirm this fix is still active?



Userlevel 5
Badge +3
Hey @jeevan_chamarthi ,



Do you know what the status is here? I know this is set to solved but this has been reported to me multiple times in the last few days.



Userlevel 2

@sai_ram : Yes, I did check the comments. I have raised a support case for this issue.

Userlevel 7
Badge +2

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

Userlevel 4
Badge +3

Yessss! Agree with all of the above comments. This and BOOLEAN field limitations have been super frustrating for me recently.

Userlevel 3
Badge +1

Hi @tom_gerth  - did you by chance get a status on this?

We’re encountering this issue with JO right now when trying to query and we’re getting data that people don’t understand as a result.

 

thanks,

 

 

Userlevel 5
Badge +3

I created a report with some Picklist fields and did export. It’s showing the Names names only, I didn’t see any ID’s are displaying instead of actual text values.

Thanks.

Reply