rule results different from preview data

@minh_phan may you please follow up on this?  This is a frustrating problem that incredibly slows me down as an admin:

@rakesh PM for Rules

Hi,

I also faced the same issue. But we have a workaround for this, i.e using “Case” expression to get the Value instead of IDs.

Rule Result Screenshot:

So Used the Case Expression to convert the Ids to Actulal string.

Screenshot:

So after the Case Experssion below is the result screenshot:

Hope this workaround will work will helps you to get the Actual Field values instead of Ids.

Thanks.

@darkknight For S3 exports, we do have a toggle which will export values in addition to GSID’s. Let me know if you want to try that.

cc: @swaroop_badam  

@phani_kumar thanks for the workaround, but that just requires extra work on the part of the admin.  It needs to do the logical translation to save us time and effort.

@rakesh I would like to know more about this - but ultimately everything should export/translate the actual value and not the GSID.

This issue also means we cannot filter the actions based on certain picklist values, and instead have to filter on the GSID of the picklist value. 

I have a number of GS → SF rules which I include filters to ensure updates are only done if the source and target data differ (to prevent unnecessary writes) but it always passes the filter because it’s comparing Source: GSID against Target: Value which will never match. 

@HollySimmons absolutely correct.  We have the same issue too.

Its completely understandable that we would want Label instead of GSID. Unfortunately the way our data models are, one would have to pick the label (do a join in this case) to get this today. That being said,

1. We will consider this feedback and work on it to make sure Rules works with picklists more seamlessly. 
2. If you want this specific to S3 export, do let us know; When we turn the toggle on, you would notice an additional field containing label  in addition to the S3 export you configured. 

@rakesh thank you.  Hopefully this gets priority.  The more we leverage MDA data the more crucial this becomes.  

Hi @rakesh 

Once we turn on this feature, it adds an additional column in the S3 export of the picklist label. Do we have any plan to replace the IDs on the original columns themselves? We have customers who plan to read the CSV export programmatically. 

Best,

Hardik

@hardik_mota - that would be a much more ideal solution. Having a legend in a separate column is better than what is currently available. But this would be much easier if the IDs were replaced by the labels. 

I agree with you, thanks @jean.nairon 

We do not have it immediately on our plan to change this Hardik. But will keep this feedback in mind for any further enhancements

Just ran into this issue with some customer journey-related data we are trying to export to our data warehouse. 

@rakesh @hardik_mota  I really hope this gets more attention.  Makes troubleshooting and confirmation so much more difficult. 

I added a +1 for this @darkknight , I feel your pain although I do not have any use cases that exacerbate this issue at the moment.

I would also add that it is impossible to Preview based on a particular Rule Run Date without adding or changing an existing filter. This is a little frustrating when I do want to run something historically and have to just assume I got everything right for that. 

I am happy to provide more detail, just not sure if this should be on the same Idea? 

Just ran into this again today where I had a status I was trying to pull into a custom object from a Timeline field, and it was virtually impossible to troubleshoot because it was the GSID for the Status picklist value instead of the actual value.

I just ran into this issue in a bionic rule. I set it up to merge on a picklist field, not realizing this would be an issue (since after all, when I preview the dataset it shows the values just fine!). Because the merge is one of many steps in the rule it took me awhile to even pinpoint what was happening. This is an incredibly frustrating experience. I understand that I can create a case expression, but that requires a) another transformation task that should be unnecessary and b) re-writing every subsequent merge and transformation task to add in the new task required to build the case expression.

It is a frustrating experience enough to have to create a case expression. It is even more frustrating to have no idea based on the preview that there would even be a problem. Then you have to find it, be shocked and enraged, and then redo a bunch of work.

@mindym  Consistency across the board is an underpinning ask for like 90% of the requests I see :/