Hi,
I would like to know whether it is possible to implement the following functionality directly in QuickSight.
Assume I have a dataset with the following structure:
date | production_line | shift1_status | shift2_status | shift3_status
The idea would be for the user to:
- Select a date from a filter.
- Select a production line from a filter.
- Select values for shift1_status, shift2_status, and shift3_status from dropdown controls with predefined values (e.g., FT, Frei, TPM).
The expected behavior would be that the selected values are written back to the underlying dataset, either by inserting a new record or updating an existing one.
Is this type of write-back functionality supported natively in QuickSight? If not, what would be the recommended architecture or approach to achieve it?
Thank you.
Hi @01267ts,
As per my understanding, no, there is not a native way to do what you are describing. It’s a read-only BI tool, you can visualize and filter data, but you cannot insert or update records in your underlying dataset directly from a dashboard.
That being said, I did find a AWS blog post that I think may be of use for your case: Perform secure database write-backs with Amazon Quick | AWS Business Intelligence Blog
The recommended architecture to achieve this is to build a lightweight input layer outside of Quick Sight that writes to your data store, and then have Quick Sight read from that same store for visualization.
A common approach would be:
Use a simple web form (e.g. an internal tool built with AWS Amplify, Retool, or even a Google Form) where users select the date, production line, and shift statuses. This form writes the data to your database (RDS, DynamoDB, or even an S3-backed data lake).
Point your QuickSight dataset at that same database table. Users can view and filter the data in dashboards, but all data entry happens through the external form.
If you’re using Amazon Quick, you could build a Flow that prompts the user for those inputs and then uses an action step to write the values to your database via an API or connector. This keeps the experience closer to a single platform.
Hope this helps and feel free to keep us updated with any new developments or questions you have regarding this issue!
Thanks for the help, was really helpful.
I am working on the Flow opption that prompts the user for those inputs and then uses an action step to write the values to your database via an API or connector.
I did a REST API connector in QuickSight (the API is working via the AWS CloudShell), so it is uploading the data into the csv, located in a S3 bucket. However, when I do in the flow an action step and I want to choose the connector , it does not appear to me the REST API connector I already created (however I have created other connectors that do show up for me in the flow, e.g Google Docs). Is there a way to call a snippet of code in the flow? It would be the curl request to the API gateway I created in AWS.
I want the data entered by the user in the flow to be inserted in a csv, located in a S3 bucket.
Hi @01267ts,
I believe the reason your REST connector doesn’t show up in Flows is that it’s a data-source/ingestion connection, not an action connector. Quick treats those as separate integration types: data access integrations feed datasets and knowledge bases, while action connectors are what Flows call in an action step. So your ingestion connector won’t appear as an action, which is why Google Docs (registered as an action connector) does.
There’s also no raw “run curl / run code” step in a Flow at this moment. The supported way to call your API Gateway endpoint is to register it as a custom action connector, specifically via the OpenAPI Specification integration type:
1.) In the Amazon Quick console, go to Integrations/Connectors and choose the OpenAPI Specification custom connector type.
2.) Import an OpenAPI 3.0+ schema describing your API Gateway endpoint, set the Base URL to your API Gateway URL (include the stage name at the end), and configure auth.
3.) Quick auto-generates the actions from your schema. Once created and shared, it shows up as an action step in Flows.
This requires Author (or higher) permissions, and an admin may need to configure the connector before it’s available to Flow creators, so if you’re not seeing the option, that’s worth verifying.
This AWS Blog does go into more detail on these steps and I think will be very useful for you! Bridging Systems and AI: A Technical Deep Dive into MCP and OpenAPI Integration Patterns in Amazon Quick | AWS re:Post
I hope this helps out your case and please feel free to keep us updated!
Hi @01267ts,
Just checking back in since this thread hasn’t received a response in a while. Was Cesar’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!
Thanks!
Hi @01267ts,
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!
