Ability for End Users to Build Custom Download Tables in QuickSight Dashboards

Q&A
,
1

Hi Team,

We are currently evaluating a requirement in our QuickSight-powered dashboards and wanted to confirm if the following capability exists or is planned.

Use Case:
In our platform , we offer users a “Data Export” section within the QuickSight dashboard where they can download data in table format (CSV export). However, the downloaded data structure is currently static — i.e., the developers predefines the fields and their order.

Business Requirement:
We would like to enable end users (our clients) to build their own download tables directly from the dashboard (not analysis) . Specifically, users should be able to:

  1. Add or remove fields/columns before exporting data.

  2. Rearrange the order of the columns in the table.

  3. Export only the customized selection of fields to CSV or Excel.

Current Limitation:
Based on our understanding, QuickSight does not currently allow:

  • Dynamic user-driven column selection.

  • Reordering of columns in visuals or exports.

  • Customization of export schema at runtime.

Even if the user is consuming data through a table visual, the export includes only the fields defined by the developers — there is no option for the end user to customize or restructure it before download.

Ask:
Could you please confirm whether QuickSight currently supports this capability?
If not, is there any plan in the roadmap to introduce such user-driven export customization (custom column selection, column order management, or custom export configuration)?

This would be extremely helpful for analytical dashboards where users need flexibility in structuring their exports without requiring developers intervention

This is how our data export section looks like :

image
image1842×706 50.7 KB

2

Hi @Nikhilburhade,
You are correct in the assumption that this capability is not currently possible out of the box with Quick Suite as building or making edits to a visual must be handled on the analysis layer for most cases. I will go ahead and mark this as a feature request but unfortunately, as AWS does not disclose information regarding their roadmap, I would be unable to comment on if this is something that is currently being planned for implementation or not.

1 Like
3

Hello @Brett

Thank you for your response and tagging this as a feature request.

I am just trying one of the parameter driven approach further handled by the calculated fields

For e.g. : -

I am creating calculated fields like below for all the data export fields which is being operated by column selector parameter :

Period_dyn :

ifelse(

in('Period', ${ColumnSelector}),

Period,

NULL

)

Similarly for rest of the fields -

image
image236×730 17.8 KB

I am facing 2 problems here

  1. If i remove hidden (original) fields from the table then it is giving me error - VISUAL_CALC_REFERENCE_MISSING and

  2. If i am selecting all the fields expect any 1 random field - i am getting the data as shown in below image :

image
image1356×492 39.6 KB

Now if i select ASP i.e. by default select all i am getting blank table as shown in image below:

image
image1336×491 20.4 KB

I have also tried - hide select all options from the control properties but same issue persists

image
image219×781 24.2 KB

Looking forward for your response on the same.

Regards,

Nikhil.

4

Hi @Nikhilburhade,
In terms of the two problems you’re encountering:

  1. There’s not really a work around for this, if you’re using a field in a calc. field and placing in a table, those fields utilized in the calc. field will also have to be included in your visual.
  2. When you end up selecting all possible values, even if you turn off the option to use ‘select all’, the control will see all options selected and change the string to ‘All’.
    It’s not picking up the values selected any longer because the control’s string value changes from including all of the selected values to a default ‘All’ and since your calc. field is essentially only looking for if the value is present in the parameter string, it’s not returning correctly.
    So I believe you’ll need to account for the ‘All Values’ in your calculated field, maybe try something like:
    ifelse(
    in(‘Period’, ${ColumnSelector} OR in(‘ALL_VALUES’, ${ColumnSelector}…
1 Like
5

Hello @Brett

Thank you for the prompt response. I think this is the most we can achieve within the current limitations. We can implement a single multi-value ColumnSelector parameter and leverage calculated fields to dynamically drive each export column.

Regards,

Nikhil.

1 Like