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. 

@bradley 

On one comment you had, this is tied to how Salesforce describes their own fields to an external system. 

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.

@rakesh So, would the string option you mentioned address this?  I feel like it wouldn’t since I’m comparing to a SFDC picklist.

Does that mean there is no way to improve the experience for admins once you’re in Gainsight and looking at two fields with the same data type that do different things?

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 

@jordan_cook 

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

Wow, I wish I knew about this earlier. Just about to ship a new JO that sends email templates based on Language (a picklist value) and had to totally re-work this when I discovered it was GSID of the Language. How can I even find each GSID associated to the dropdown value?

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.

@rakesh@Azad Are there any updates on this improvement?

@rakesh Has there been any progress on this?

Hi @rakesh , any progress?

This is already possible in HRE.