Skip to main content
New Idea

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

Related products:CS Rules Engine
berin_bezmen_9a2cd6
  • berin_bezmen_9a2cd6
    berin_bezmen_9a2cd6

bradley

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
Forum|alt.badge.img+3
  • Helper ⭐️⭐️
  • 367 replies
  • June 5, 2023

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


jordan_cook
Forum|alt.badge.img+2
  • Contributor ⭐️⭐️⭐️⭐️
  • 46 replies
  • 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
Forum|alt.badge.img+2
  • Contributor ⭐️⭐️⭐️
  • 15 replies
  • June 21, 2023

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


TMaier
Forum|alt.badge.img+5
  • Helper ⭐️
  • 175 replies
  • 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
Forum|alt.badge.img+10
  • VIP ⭐️⭐️⭐️⭐️⭐️
  • 354 replies
  • 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….


bradley
Forum|alt.badge.img+7
  • Author
  • Expert ⭐️
  • 1129 replies
  • August 10, 2023
sarahmiracle wrote:

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
Forum|alt.badge.img+8
  • VIP ⭐️⭐️⭐️⭐️⭐️
  • 426 replies
  • 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 ☹️


alizee
Forum|alt.badge.img+12
  • VIP ⭐️⭐️⭐️⭐️⭐️
  • 659 replies
  • March 5, 2024

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


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings