Skip to main content
bradley
Expert ⭐️
June 5, 2023
New Idea

Improve SFDC Picklist and MDA Picklist Comparison in Horizon Rules/Data designer

Related products:CS Rules Engine
  • June 5, 2023
  • 8 replies
  • 210 views

Context:

If you have an SFDC Picklist and an MDA Picklist that both have the same values, you cannot easily compare them. For example, your picklist in both systems looks like this:

  • Value 1
  • Value 2
  • Value 3

with your field names of MDA_Picklist and SFDC_Picklist

If you want to filter records where MDA_Picklist = SFDC_Picklist it won’t work, because the picklists are treated as GSID and SFDCIDs, respectively, and obviously won’t match.

To date, you’ve had to solve this by adding transformation steps and Case fields (which are tedious and hard to manage) to convert a particular Picklist value to a String output, and then compare those case fields. Or fully duplicate picklists as string fields.

 

Problem:

Data Designer (DD) and Horizon Rules (HR) give us the ability to easily duplicate an MDA Picklist as a String picklist “Label” field. That only solves half the problem.

SFDC Picklists can be “mapped” to an MDA picklist but you still cannot compare it to an MDA Picklist in a filter such as MDA_Picklist = Converted_SFDC_Picklist.

You also do not have the option to duplicate an SFDC Picklist to a String label equivalent like you do with an MDA Picklist.

While Gainsight states that “SFDC Picklists are treated as Strings”, that is ONLY true for joins, and possibly if you’re using DD and publishing it as an MDA. It does not work in data prep to compare values.

 

Request:

The request is to solve this requirement to use case statements in data prep if you want to compare MDA and SFDC Picklists. 

An example of a useful solution would be to give us the same duplicate to string Label field like we have for MDA picklists. 

Another example would be when you map an SFDC Picklist to an MDA picklist, actually let you compare values to an MDA Picklist as if it were one.

8 replies

andreammelde
Helper ⭐️⭐️
June 5, 2023

This causes SO MUCH additional work….. Ideally you should be comparing the display value not the IDs

Andrea Carroll
jordan_cook
Contributor ⭐️⭐️⭐️⭐️⭐️
June 16, 2023

We struggle so much with this. And some of our picklists in SFDC don’t return the picklist value name as well, so we get to try and compare picklist IDs in Salesforce with Picklist GSIDs in Gainsight. It’s a mapping nightmare. And heaven forbid a value gets changed in Salesforce without our knowledge.

mdowney2
Contributor ⭐️⭐️⭐️
June 21, 2023

All this gets even further complicated if it happens to be a multi-select picklist ☹️

Michaela
TMaier
Helper ⭐️
August 9, 2023

Currently dealing with this and will be using the Case Statement workaround, which is going to increase the amount of time I have to spend on this by a noticeable amount. If I find that the picklist in question has too many values to be handled in a single Case, that adds yet another layer of tedium and complexity to the job.

 

For context, the business case here is that I’d like to evaluate data quality between SFDC source and GS destination records. If a particular picklist field doesn’t match between the systems, I intend to use the data design I cooked up as the source for a true-up rule to adjust the GS picklist value accordingly. Why these don’t already match is a long story I won’t subject you to but it seems like a common enough use-case.

 

I really enjoy being able to filter on field vs field values and I hope you guys consider expanding that useful tool to handle these cases as well.

sarahmiracle
VIP ⭐️⭐️⭐️⭐️⭐️
August 10, 2023

I just want to clarify that this workaround is not an acceptable or feasible workaround for all use cases.

This (below) is not the workaround:

  • Output name: Health Risk Reason String
  • Case 1: If Account ID != Null, then “Health Risk Reason”….Default “Health Risk Reason

This workaround, which works for other “turn to string” needs (like turning rich text → string), will not work for this need, as it just spits out the GSID as a string...

Instead, the workaround is actually:

  • Output name: Health Risk Reason String
  • Case 1: If Health Risk Reason = “Red”, then “Red”….Default “Red”
  • Case 2: If Health Risk Reason = “Yellow”, then “Yellow”….Default “Yellow”
  • Case 3: If Health Risk Reason = “Green”, then “Green”….Default “Green”
  • ……..so on and so forth

The limitations on case expressions in Horizon Rules and Data Designer make this workaround much more complicated and significantly more time consuming if you have a multiple picklists with many values (lets say...10+ values).

 

Sharing here in case someone else thought that the “case statement workaround” was thought of as the simple option. 

 

I am tasked with creating a correction rule that is planned to run nightly to rectify fields that fail through real time activities in the SFDC Connector. We have experienced multiple silent failures from real time activities that have fueled doubt in the integrity of this feature, thus forcing us to create our own nightly correction rule. Except now….I can’t do field comparisons for the correction rule….

Customer Success Systems Admin @ Amplitude, 3x Gainsight CS Ops Product Council Member
bradley
bradleyAuthor
Expert ⭐️
August 10, 2023

I just want to clarify that this workaround is not an acceptable or feasible workaround for all use cases.

This (below) is not the workaround:

  • Output name: Health Risk Reason String
  • Case 1: If Account ID != Null, then “Health Risk Reason”….Default “Health Risk Reason

This workaround, which works for other “turn to string” needs (like turning rich text → string), will not work for this need, as it just spits out the GSID as a string...

Instead, the workaround is actually:

  • Output name: Health Risk Reason String
  • Case 1: If Health Risk Reason = “Red”, then “Red”….Default “Red”
  • Case 2: If Health Risk Reason = “Yellow”, then “Yellow”….Default “Yellow”
  • Case 3: If Health Risk Reason = “Green”, then “Green”….Default “Green”
  • ……..so on and so forth

The limitations on case expressions in Horizon Rules and Data Designer make this workaround much more complicated and significantly more time consuming if you have a multiple picklists with many values (lets say...10+ values).

 

Sharing here in case someone else thought that the “case statement workaround” was thought of as the simple option. 

 

I am tasked with creating a correction rule that is planned to run nightly to rectify fields that fail through real time activities in the SFDC Connector. We have experienced multiple silent failures from real time activities that have fueled doubt in the integrity of this feature, thus forcing us to create our own nightly correction rule. Except now….I can’t do field comparisons for the correction rule….

Also, as someone pointed out in the Slack community, best of luck if you have a multi-select picklist. 🕶

romihache
VIP ⭐️⭐️⭐️⭐️⭐️
March 5, 2024

Oh, just saw this topic popping up in Slack and got a case of PTSD. So much additional work that adds zero value just to be able to compare two fields ☹️

Continuous improvement is better than delayed perfection
alizee
VIP ⭐️⭐️⭐️⭐️⭐️
March 5, 2024

Our opportunity to make this a priority as product council member, this and everything that has to do with picklists. 

The most expensive part of building is the mistakes. That's true in construction. Not so much in CSOps. So ask questions, make mistakes and learn. All views expressed here are my own.