Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Apr 13, 2026 7:39:50 AM
Dec 10, 2025 9:31:59 AM
This document contains frequently asked questions for the Qlik Write Table.
Content
A: After 90 days, changes will be permanently deleted from the change store and will no longer be available in the Write Table chart.
There are three options to set up a scheduled extraction of these changes:
A: Every new change is appended to the change store, together with a primary key and the metadata to track which user made the change and when they made it.
A: When new changes are made, they are appended to the change store with a 90-day TTL (time to live). The write table displays the latest change in the chart, and you can hover a cell in the chart to see previous change values with the user's info and timestamp.
The full history of all changes can be retrieved through the List Change Store History block in Qlik Automate or through the /changes endpoint in the API (until their 90-day TTL expires).
A: The write table is provided as an included capability.
A: No, the Write Table is only available in the following editions of Qlik Cloud:
A: No. Adding and configuring the Write Table in a sheet requires the Manage write table charts user permission. This permission is automatically enabled in the User default role. Tenant admins can manage the Default user role or create a custom role that includes this permission.
A: Section access is applied only to data that is in use by the Qlik engine.
The records shown in a write table depend on the primary key, which is configured using engine data. Therefore, if the write table is used in an app that uses section access, the records shown in the table will be restricted by section access.
However, the write table interaction data, such as edits created during analysis sessions, are stored in a change store. This happens separately from the engine, meaning Section access is not applied on a change store or on the change-stores API.
Therefore, users with permission to read from the change-stores API will be able to read all data from a change store regardless of the Section access rules.
For additional details, see Section access limitations.
A: Users with the full Manage write table charts permission can access the change-stores API and use it to read changes from change-stores they have access to. It is also possible to create an OAuth credential that has limited API access to the change-stores API. Assigning this limited access to a user is not yet possible.
A: Users with the full Manage write table charts permission or the Read and write access only permission can use the Write Table chart to read and write changes through the chart.
See Write table permissions for details.
A: Please make sure that Touch screen mode is disabled for your app. The write table is read-only when touch screen mode is enabled.
A: Text input box (manual user input) and dropdown (single select).
A: Not as of yet. For now, the values are a hardcoded list configurable in an editable column’s settings.
A: No, this is not supported and not on the roadmap.
A: Yes, the write table is available in the government editions of Qlik.
A: No, the write table is only available on Qlik Cloud. There are no plans to make it available in on-prem versions.
@Emile_Koslowski when I delete an app containing a write table, the underlying change store still exists (but clearly with no app referenced).
In this case, the change store will be still deleted in 90 days?
Or in the future will be added a /DELETE api?
Hi @Emile_Koslowski ,
In the Pricing and Packaging section, it's mentioned that the feature is available for Qlik Cloud Analytics Premium. However, I can't see the write table visualization or the permission for 'Manage write table charts' in the Administration portal for a Qlik Cloud tenant with a Premium Light subscription. Has it been omitted from Premium Light?
Regards,
Nak
Hello,
Can you add a section to how manage the publishing of an application with a write table ?
When I publish, ID changes and nothing work.
There is a lot of example in QLik community but I don't see how you manage the change store id and column ID when an app is published.
Thanks
For me, the important understanding that I came to have is that each change store has it's own id. So if you develop an app with a change store, and then you publish that app to a new location, that published app will have a different change store with a different change store id. Testing you do in your development app change store will not be reflected in the published change store. Data entry in the published change store will not be seen in the development change store.
If you develop accompanying REST connections, data load scripts in accompanying helper files, or anything else that references the change store ID in development - Those resources will still point to the development change store when you publish your "write-table containing app" into production.
When it is time to move an app with a change store into production, along with any agent jobs or helper apps that accompany the developed app, I start by publishing the app with the change store. I then publish any accompanying helper apps or other resources that point to that change store. Next I go into the published app -> to the write table, and I press the small "information" button next to the write-table save button. That will show the published change store id. I then copy that change store id into any REST connection, helper app, etc. that needs the new change store id.
I hope I have this all down right. I hope that I have intuited how Qlik manages multiple instances of dashboards with a write tables, and how the change store gets reproduced as an app is published or copied.
Please do correct me if I have anything wrong here.
This is also important: When the change store of a REST connection changes, the non-key field names of the REST connection may also change (because they contain seemingly random numbers as part of their field names).
Also important, when you publish a dashboard with a write table, you need to go into that write table and add an entry into each editable field. This will create a place-holder in the change store for each field. Only then will the REST connection see all of the fields in the newly published change store. Sorry that these little revelations are trickling out.
Hi community! 👋
Please help me figure this out. I have a question regarding the 90-day data retention policy in Qlik Write Table:
If I want to prevent a record from disappearing/being deleted from the Write Table widget after 90 days, is it sufficient to periodically update (or re-save) that record?
Does updating a record reset the 90-day TTL timer for that specific primary key/row, or will it still expire based on its original creation date?
Thanks in advance! 🤝
Hello @StanislavChernenko
I've reached out to our experts and found this answer for you:
Each value saved in any editable column has 90 days TTL. To periodically update a cell with the same value to get a new 90-day TTL, the user needs to clear/update the original value first to get a new unsaved change, re-enter the same original value, and then save.
Retyping the same original value immediately in the cell won't create a new change.
Should you need more assistance, I recommend posting follow-up questions directly to the forums, where your active Qlik peers can help you.
All the best,
Sonja