rule results different from preview data

Hi all,

We are working on improving the picklist handling in our data processing layer (Rule Run, Data Designer Run, JO Run, etc.). This should avoid the above-mentioned workarounds with respect to the picklist. However, there are quite a few considerations before we can deliver this - the primary concern is involving the performance (Label instead of id means an additional join internally). We will first prototype and check performance impact with production data and if the results are good, would then pick it up. 

Let me know if there are any additional thoughts on this one!

@rakesh I would trade a bit of a performance hit for the savings I would get in troubleshooting/testing time.

100% with this. Unless there is some massive performance hit where it’s barely useable I’d rather have better functionality that requires more development time every time.

This is getting more and more frustrating now that I am on NXT.

Exactly how am I supposed to interpret Rule Execution logs like this - and with TWELVE Actions - in order to validate that the rule is doing what I want it to do.  It’s SO time-consuming.

I’m trying to be a conscious data steward and only update SFDC records when the value held in GS differs from what’s currently in SFDC, but with picklists it’s not possible with doing case expressions and I have too many that they don’t fit on one task (plus it’s just annoying and not future proof, ugh). 

You (GS) KNOW the value of the picklist in GS, you KNOW the value of the picklist in SF, it should be possible to use a filter of GS /= SF without having to do the above. 

I can’t think of any possible example where I would want to compare (or match like those commenting above) a GS Picklist ID to something. It’s always going to be the value. 

Please fix this….

+@Ritesh Sharma @rakesh  

Just ran into this on a JO I’m looking to implement where I have to know the contact role for a participant, and the preview shows me the name, but the participant execution shows the GSID value. I’ve hit this issue before in Rules, but in JO it’s quite frustrating as I’m hoping to display these values in reports to users. It also would help me confirm my participant source is set up correctly.

+1

We regularly use the report builder before building a JO to have an idea of recipient numbers, specially when we are being quite targeted in our campaigns. And we’ve also noticed the inconsistency across report builder and rules. 

@rakesh would you be able to share the latest?

Hi All,

The solution to the problems discussed here need multiple steps. 

1. For picklists, we are solving this at fetch itself - https://share.getcloudapp.com/p9uOYvXv. In Data Designer, we already have it in production, 
2. Rules Horizonization will bring the above experience to Rules Engine. This means you can always add a name field, for any field in data prep step itself to compare. 
3. Actions results in Rules Engine

I suspect the 3rd step is of utmost interest to every one here. One question - I am assuming that this problem exists when you download the execution history file. Would you be willing to wait a while (a few mins) after you hit download for us to generate the file which has a new column for name for every column with GSID’s? 

As per my previous response, applications work on ID’s, not name. We are showing the same file that a system needs to function to you to debug today. If we auto generate names for every file to make them more readable, every rule will take more time. This is not a path we want to take. Estimated 100-400 customer’s rule might start timing out. cc: @veera