We show the display name in the report itself, but as soon as it's exported, we get the GSID that we are unable to decode and understand the text value.
Best answer by rakesh
View originalMDA dropdown values show GSID when exported
Userlevel 5
+3
We've noticed that when including an MDA dropdown list field in a report, we get the GSID values when we export said report, versus the value's display name.
We show the display name in the report itself, but as soon as it's exported, we get the GSID that we are unable to decode and understand the text value.
We show the display name in the report itself, but as soon as it's exported, we get the GSID that we are unable to decode and understand the text value.
Page 1 / 2
Userlevel 1
+1 to this. I've been looking for a solution to this problem when exporting to S3 via Bionic rule - only the GSIDs for MDA dropdown values are exported, not the actual value. (Same if you transform the data in any way - still only GSIDs are exported.) Also the GSID isn't displayed in the Category (dropdown) UI so you have no way to marry the values to the correct account fields post-export.
Userlevel 4
Yes - this is definitely an issue. I found a lot of issues in copilot when i go to use one of the dropdown fields as a filter, and have to figure out the GSID code instead of using the text value. For example, instead of filtering on something like "Mid-Market" i have to filter on the full code: 1I0054U9FAKXZ0H26HUNX1G915T5I65JS9C4. While this is a pain, the reports are more of an issue. In the report, the field display's correctly in the view, but when you export it out, it has the GSIDs in the export file, which is extremely confusing for users.
It would seem that if we can use the dropdown lists to filter reports, we should be able to export it out with the text values and also use it to filter in copilot.
My current workaround is to also make a text field that i map the values to, but that means i have to create 2 fields for each field i want to create a dropdown field for. That is a lot of extra work and is confusing if you have other users creating reports that might not know to use the nondropdown fields for the visual portion of the report.
It would seem that if we can use the dropdown lists to filter reports, we should be able to export it out with the text values and also use it to filter in copilot.
My current workaround is to also make a text field that i map the values to, but that means i have to create 2 fields for each field i want to create a dropdown field for. That is a lot of extra work and is confusing if you have other users creating reports that might not know to use the nondropdown fields for the visual portion of the report.
Userlevel 4
Totally agree - i had to run reports and filter on specific accounts to match up the GSIDs to the values. Bit of a pain.
Thanks Tom for bringing this up. We are working on a fix, will be able to update this thread as soon as the fix is pushed to production.
Userlevel 5
Hey Jeevan- Just came across a customer for whom the export from report builder still shows GSID's rather than the value/label of the dropdown list. Could you confirm this fix is still active?
Userlevel 5
+3
Hey @jeevan_chamarthi ,
Do you know what the status is here? I know this is set to solved but this has been reported to me multiple times in the last few days.
Do you know what the status is here? I know this is set to solved but this has been reported to me multiple times in the last few days.
Userlevel 3
+1
Hi
We’re encountering this issue with JO right now when trying to query and we’re getting data that people don’t understand as a result.
thanks,
Userlevel 5
+3
I created a report with some Picklist fields and did export. It’s showing the Names names only, I didn’t see any ID’s are displaying instead of actual text values.
Thanks.
Userlevel 2
+1
Any resolution on this. We just set up an S3 export for our data team and all the picklist data came through as GSIDs.
Userlevel 2
I too have the same issue, we are trying to export data to S3 and all the picklist data came through as GSIDs.
Userlevel 7
+2
Userlevel 2
+1
As an update - I did open a ticket on this. It was something that was fixed with flipping something on the backend. I’m not entirely sure if that opens all up all pick list fields to show the value instead of the ID, or just the one I was writing in about.
Userlevel 6
I see multiple product areas being discussed here:
- Reporting → When you export a report which has a dropdown value we are currently showing labels only, not GSID’s. If anyone is getting GSID’s in any scenarios, I recommend raising a ticket.
- Rules S3 export → We have a backend flag which when changed will also send the label in addition to the GSID. This should be on for newer customers by default, for our older customers who might have already created some data flows using GSID’s we could not automatically do this change for all customers. Please reach out to support if you want this for your org
Hope this covers everything
Userlevel 7
+2
Userlevel 2
Userlevel 7
+2
This is a pretty major issue in my opinion. I see that I can ask support for including the name too, which I will do. But the issue still remains that we can’t use MDA picklists in string formulas at all in the Rules Engine - i.e. you can’t do a LEFT formula, you can’t convert them as a string using Case Expressions, etc.
This is especially frustrating considering you can do all of the above with SFDC picklists. Why would our MDA picklists not function the same way?
Yessss! Agree with all of the above comments. This and BOOLEAN field limitations have been super frustrating for me recently.
Userlevel 7
+2
Here’s another scenario where storing the picklist values as GSIDs leads to frustration
Userlevel 7
+2
Userlevel 3
Came across this issue just yesterday and had to push to a new object string field just to work with it.
Userlevel 7
+2
Userlevel 3
Agreed, was adding on to the annoyance and extra work/resources that is needed to work with this lack of a feature.
Userlevel 7
+3
Adding to the chorus of voices here, the ability to export picklist values as they are labeled quickly and at scale (without workarounds of extra tables, fields, rules to manipulate extra tables/fields, CASE statements, etc.) would be a big win.
How do transition this need beyond a “Question” thread to become an idea we can upvote?
Userlevel 3
Userlevel 7
+2
- This caused our Snowflake team to do some hefty data management acrobatics on import because the native picklist/multipicklist field only exports the GSID.
- This prevents us from being able to leverage the data in external API action in various ways because the field natively only exports the GSID.
- This prevents us from being able to do field comparisons (i.e. between Salesforce and GS) because one side natively contains a GSID, without making custom case expression fields that limit you to 10 cases.
- This makes it very difficult to use Rule/Program execution logs.
The workaround where Gainsight exports an extra field containing the label should be considered a workaround only. When would an admin ever use the GSID value of a picklist/multipicklist field over the label (especially when we have no way of looking up the GSID of each value)?
This has become a bigger issue for us in NXT where admins have greater ability to create custom fields and so this issue will only grow, not diminish. Admins should not be required to contortion complex and costly solutions to work around such a gap.
Page 1 / 2
Reply
Login to the community
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.