Under Consideration

rule results different from preview data


Userlevel 7
Badge +1
After talking with a customer via a support case we discovered that when you preview the results of a rule they will not show the same as the results show.

For instance, in the first image below you see a preview data set to a rule, this shows the name of the data in the field. "Guided" is an example.

But in the second image this is a rule run result and it shows an ID (blanked out for privacy purposes).

This is as design but in the future myself and others would find it useful for these to be matching. Troubleshooting a rule or data validation is very hard when these do not match up.

The reason it is like:

The execution itself uses the actual data so we have GSID's for Picklist values in the logs.

But in rule setup preview we are converting these GSID's to Picklist names to avoid confusion while setting up the rule.

The way we would like it to work:

Show the datasets as the same so that we can validate and confirm data easily.






31 replies

Userlevel 7

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!

Userlevel 7
Badge +2

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

Userlevel 7
Badge +3

@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.

Userlevel 7
Badge +2

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.

 

Action 12 field mapping
Action 12 tab

 

Userlevel 7
Badge +1

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….

Userlevel 6

+@Ritesh Sharma @rakesh  

Reply