topic Re: Write Table clarifications in App Development

Write Table clarifications

mdf — Thu, 15 Jan 2026 09:20:26 GMT

Hello everyone,
I have watched some presentation videos about the new Write Tables and I would like to clarify a few points.

From what I understand, Write Tables allow updates only on one or more columns associated with an existing record based on a defined key, but they do not allow inserting new records. Is that correct?

For example, if I want to manage a forecast by country, I could define the country as the key and have an editable column with the forecast amount. In this case, if I need to add a new country, is it possible to do it directly in the Write Table, or must the country already exist in the underlying dataset?

Another point that is not completely clear to me is the 90-day retention of the changes. What exactly happens after 90 days?

Continuing with the forecast example, if this table is used to display the forecast throughout the year, would the editable values for rows that have not been modified for 90 days be removed?

I understand that modified data can be extracted before they are deleted, but in a management table like this I cannot clearly see the practical usage. For example, I cannot write the edited value into another non-editable column within the same table.

Thanks in advance for any clarification.

Re: Write Table clarifications

Daniele_Purrone — Fri, 16 Jan 2026 14:58:32 GMT

Hi @mdf ,

as you could guess, the write table does not allow you to create new records. You will need to add the country to the app's data sources.

After 90 days, the data is removed. If the data needs to be permanent, we recommend importing into the data model via the APIs regularly.

Re: Write Table clarifications

mdf — Fri, 16 Jan 2026 15:10:52 GMT

Hi Daniele,
thank you.

I’m not sure I fully understand: if I import the modified data into the data model via API, I will have the column with the imported (modified) data in the model,
but the editable column will remain a different one, if I understand correctly.

From a forecast management perspective, would this mean that I need to have the key (the country), a model column such as “Forecast_1”,
and then an editable Write Table column (“Forecast_2”) that gets cleared after 90 days?

Thanks

Re: Write Table clarifications

Daniele_Purrone — Fri, 16 Jan 2026 15:59:57 GMT

It depends on what you want to achieve exactly, but that's a possible way. Using the second column only for amazing the data from the previous column when necessary.

Re: Write Table clarifications

mdf — Mon, 19 Jan 2026 06:46:53 GMT

Thank you,
It seems impractical to me. If I had 12 columns to handle a forecast for the 12 months of the year, I would need 12 columns loaded in a template to display the data without it being "lost" after 90 days and another 12 to allow the user to edit the same data.

Re: Write Table clarifications

Daniele_Purrone — Mon, 19 Jan 2026 10:19:41 GMT

It might work better for some use cases than for some others, but the idea was always that the "write" data was not meant to be permanent.

Re: Write Table clarifications

mdf — Mon, 19 Jan 2026 13:08:39 GMT

Thanks Daniele

Re: Write Table clarifications

marksouzacosta — Mon, 19 Jan 2026 14:54:10 GMT

Hi @mdf ,

Regarding the 90-Days retention and how you can manage that, I have created two YouTube videos. Following the links:

Native Qlik Write Back is Here: Store to Snowflake & QVD
https://youtu.be/B50XAm3yJMg

Bypass the 90-Day Limit: Incremental Load for Qlik Write Back
https://youtu.be/Ejp1I3Hts_g

Regards,

Mark Costa

Re: Write Table clarifications

mdf — Mon, 19 Jan 2026 15:07:58 GMT

Hi Mark,

I saw the video, thanks.

It's just I bit confusing having to have the columns duplicated in a Forecast management, one to have the data stored so that it stays after 90 days, and one to edit the same value.

Thanks

Massimo