rule results different from preview data

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.

Hi Cameron,


I agree with you that the rule results and preview results should be consistent. There need to be some design level change to make this happen and we are exploring ways/options to achieve the same. The timelines are not known yet. I will keep you posted on the same.



Probably goes without saying, but this also applies to exports of the data. I just created a rule to map Customer Info to Company and wanted to pull Status from both, but the Status field from Company exports the GSID for that dropdown value, not the value itself. And I cannot figure out how to map the GSID for that Status to the actual value

@jitin_mehndiratta Any update on this?

This is already a pain for us, but will become an even BIGGER pain as we want to be able to export data from Gainsight to S3 that will be picked up via Informatica for inclusion in our data warehouse.

We have to have the ACTUAL data - not an ID.

@dan_ahrens this really needs a solution ASAP. Since we're having to create Bionic Rules to supplement reporting gaps, we need to be able to export the actual values not long IDs.

cc: @kelly

@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


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.


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.


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




@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 

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. 




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? 

End Proctoring-

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 :/