Quick Sight Challenge Parameterization

Q&A
,
1

Use Case

Generating Amazon QuickSight reports by dynamically passing parameters.

Objective

The primary objective is to pass parameters dynamically into QuickSight datasets and generate reports in a reusable and scalable manner.

Current Areas of Focus

We are currently exploring the following approaches:

  • Embedding complex inline SQL queries with parameters within QuickSight datasets.

  • Avoiding Stored Procedures and attempting conversion to Views, since QuickSight does not support execution of Stored Procedures directly.

  • Enabling dynamic parameter passing instead of hardcoded values to support scalable and reusable reporting solutions.

  • Converting Stored Procedures into SQL Functions where feasible, because Views cannot support parameterization and the Stored Procedure logic is highly complex.

Challenges Observed

The following technical limitations and challenges have been identified:

  • QuickSight is unable to save datasets when complex inline SQL queries contain parameters, multiple joins, and conditional logic.

  • Views cannot be parameterized, making them unsuitable for our reporting requirements.

  • SQL Functions execute successfully only when parameter values are hardcoded directly within the query.

  • Dynamic parameter passing to SQL Functions is currently not supported by QuickSight at the dataset layer.

  • AWS Support confirmed that this is a known QuickSight limitation related to metadata/schema discovery during dataset validation.

2

Hello @hariprasadkanagaraju, welcome to the Quick Community!

Out of curiosity, what is the exact goal of your question here? I want to make sure I target the specific need you are looking for, but I can try to provide some relevant information.

First of all, I am interested when you are hitting this limitation:

QuickSight is unable to save datasets when complex inline SQL queries contain parameters, multiple joins, and conditional logic.

I have added a lot of logic into the SQL statement and not really run into this problem.

Then, in regards to dynamic parameter passing, you can’t dynamically change the actual parameter that is being used in the SQL statement, but you can dynamically update the value via code when managing the dashboard via embedding. The ultimate restriction is going to be data type, but you can create a default parameter for each data type you want to filter by, then just set each one that isn’t used to the default value for select all.

To try and simplify the query in Quick as much as possible, you can always import the aggregated view into Quick with a SQL statement, then just add the required parameters within the where clause to filter.

Please let me know what items I am missing here, and I can help you dive further into the proper solution for your issue. Thank you!

3

Hi @hariprasadkanagaraju,

Just checking back in since this thread hasn’t received a response in a while. Was Dylan’s reply helpful to you and/or were you able to find a solution yourself in the meantime? Please help the community by marking this answer as “Solution” or following up in general within the next 3 business days!

Thank you!

4

Hi @hariprasadkanagaraju,

Since I haven’t received any further updates from you, I’ll treat this inquiry as complete for now. If you have any additional questions, feel free to create a new post in the community and link this discussion for context.

Thank you!