Filtering on Picklist values in Rules

Related products: None

This is a carryover from https://community.gainsight.com/cs-ideas-21/rule-results-different-from-preview-data-30237 which is related, but not exactly the same.  Felt this warranted its own post (and I couldn’t find one already out there)

When comparing a source SFDC picklist to an GS dropdown list in Rules Engine filters, equivalency is not correctly established because the SFDC picklist renders as the actual value but the GS dropdown renders as the GSID.  This results in erroneous filtering.

One (of several) use case: since Gainsight doesn’t have a native way of keeping Contacts in sync with Person records (in the reverse direction) we have a rule that pulls changes to Person records and syncs them back to Salesforce.  And I only want them to update the Contact if the values on the Person record differ from the Contact record.

We have 5 picklists on the SF object - 2 of them map to Dropdown lists in GS and the other 3 map to strings - that we need to keep in sync.   Trying to compare the values between the 5 fields in both locations isn’t possible in either dataset filters or action filters.

The suggestion (from the previously referenced post) was to create a pseudo-string field using the Case Expression formula in the Transformation task.  While this (mostly) works, it’s very cumbersome.

For my example, I end up having to create SEVEN virtual fields (4 for the SF Picklist → GS Dropdown fields - because BOTH sides have to be a string - and 3 for the SF Picklist -> GSString fields - because the target fields are already strings)

While this would work, the Case Expression is limited to 10 fields, and one of my picklist has 14 options - so I’m kinda screwed on that one.

Some folks may say “Just have the CSMs update the Contact record” - but we have security restrictions on the Contact record - also it kind of defeats the purpose of having Gainsight be the one-stop shop. 

This is a sizeable gap that causes frustrating administrative pains - hoping it can get prioritized.

FYI @rakesh @phani_kumar @HollySimmons 

thanks for separating this out @darkknight 

+1 to this request for sure


 Hi @darkknight 

Totally agree with what you said. And creating the Case Transform for one Picklist field with fewer(less than 10) Picklist value is fine, but if we have more Picklist Fields and each field has more than 10 values and creating the Case transform tasks is a cumbersome process.


@sai_ram can you raise this to Product please?  It is quite difficult to keep SFDC and Gainsight in sync when picklists are involved...


@darkknight Thanks for resurfacing this request. Our product team is planning a lot of new changes on rules engine. I am redirecting this to them for more visibility. 


@darkknight Yes! This is an issue on many of my rules - fixing this would create much shorter run times for Gainsight rules and help with auditing between Gainsight and SFDC. 

 

There are plenty of instances where Real-time rules do not push to SFDC and there’s really no way to trace that back (as connectors only go one way). So mismatch field values would be key in preventing these discrepancies. 


Running into this issue yet again. 

Since I cannot add Salesforce fields directly to the C360 Attributes on NXT, I have replicated a Salesforce Account picklist on the Company object, and need ensure that Gainsight and Salesforce stay in sync when users edit the picklist in GS.

I have Real Time Rules set up to do this, but since Real Time rules are a bit inconsistent/flaky in regards to if/when they decide to fire (or fail to notify me when they fail) I need to create a “clean up” rule that looks for mismatches and shores them up nightly.

Here’s where the current idea comes into play and where my knees scrape across the pavement:

I cannot compare the Picklist Values in Gainsight with the Picklist Values in Salesforce without creating (and keeping updated) a case statement to make the translation of GSID to Picklist Label so that I can compare the GS Picklist Label to the Salesforce value. 

I 👏🏻 should 👏🏻 not 👏🏻 have 👏🏻 to 👏🏻 do 👏🏻 that 👏🏻!

I want to know what Gainsight’s plan is to fix this egregious pain. 

@rakesh  @anirbandutta 


@gopal_rao_kallepu, @rakesh could you pl take a look at this? 


Checking to get answers here


Agree Jeff, you shouldn't have to do that. There are 2 ways when we look at plans from Gainsight to address this.

  1. Just like how it is in Real Time Rules, you should be able to map Picklists even in Rules actions. The experience shouldnt be any different 
  1. In Data Designer, we have introduced this ability to either have Picklist as an ID or as a Label as a part of our initiatives to make picklists easier to work with.  

With Rules Horizonization, this will be one of the many enhancements we will bring to Rules from DD when we use DD for data set up. With this enhancement, you can directly load the String value to SFDC field. 

 

That being said, the statement you said below is not my impression of Real Time rules. Could you please elaborate this? Is there any support ticket I can follow to understand this better?

Real Time rules are a bit inconsistent/flaky in regards to if/when they decide to fire


@rakesh thank you for this update! It’s good to know this is in the works. Do you have a target GA timeframe for the rules horizonization?

 

As for RT Rules, I have been attempting to utilize them the last few days to update several fields in SF when the corresponding fields are edited in GS. The problems seem to occur mostly in rules where I combine multiple fields into a single RTR. I haven’t created a support ticket because I just split each field out into their own separate RTR which seems to be working ok for now and frankly I don’t have the time or patience to deal with the frustrating support experience on this.


@anirbandutta if this is in development, may we have the status updated to reflect that? Thank you!


RTR Split!

@darkknight  - LOL   My one run at RTRs was a Snapshot and I had to separate all the actions in separate rules exactly as you mentioned. BTW - the rules cannot fire from updates via the SFDC Connector 2.0 sync. I have another rule that gets all company values that are associated with the RTR and I fetch/post the value to trigger the RTR to run. In the end, we converted back to Bionic rules and moved on.  We did engage Support @rakesh (183943) - then just abandoned it in the back and forth.


No StatusPlanned

We did engage Support @rakesh (183943) - then just abandoned it in the back and forth.

I feel that right in my heart.


The problems seem to occur mostly in rules where I combine multiple fields into a single RTR. I haven’t created a support ticket because I just split each field out into their own separate RTR which seems to be working ok for now

Is this the case even with the OR condition in Advance Logic?

 


@rakesh yeah even with the advance logic.