rule results different from preview data
None
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.
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.
Sign up
If you ever had a profile with us, there's no need to create another one.
Don't worry if your email address has since changed, or you can't remember your login, just let us know at community@gainsight.com and we'll help you get started from where you left.
Else, please continue with the registration below.
Welcome to the Gainsight Community
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
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!
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.
Hi All,
The solution to the problems discussed here need multiple steps.
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?
@veera
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: