Properties - Writeback Settings - Load Script, Audit Columns, Reload

Vizlib Input Form has a Writeback Settings menu to make changes to your writeback configuration quick and easy to manage.

Writeback settings are found in the right property panel, below the Input Fields menu. In this article we're going to focus on the properties for the Load Script, Audit Columns, and Reload sections. If you need further information on the Destination section, you can find a link to the article here.

This topic contains the following sections:

Load Script

Note: Load Script settings are only displayed for QVD destinations.

The Load Script settings (Figure 1) allow you to inject (or update) a data load script containing writeback information into the data load script for your app. You need to enter the Data Table Name used to create the input form, then click Inject Load Script (or Update Load Script if a script has already been added). If the script is added, you'll receive a confirmation. If you return an error, you'll receive details about the information you need to correct.

Figure 1: Load Script

Audit Columns

If you would like to build up a record of your input form changes, you can use the Audit Columns section to set this up. There is a Standard audit trail set as the default (Figure 2), or you can choose None to disable the function completely.

You can select the Timestamp format that you'd like to use from the drop-down, or use the Qlik Sense expression editor to customise the Timestamp label and User label.

Figure 2: Audit Columns

You can choose to customise the Timestamp format of your audit trail by selecting the Custom option from the drop-down. The Timestamp custom format will be displayed, and you can use the Qlik Sense expression editor to enter the format you need (Figure 3).

Figure 3: Audit Columns Custom

Reload

The Reload section (Figure 4) contains settings relating to when a reload action is performed on the writeback table. You can choose from:

  • No reload - No reload when writeback is called.

  • Reload app (default) - The app is reloaded when writeback is called, overwriting any existing data. A potential use case would be before generating the latest version of a report.

  • Partial App Reload - The app is partially reloaded when writeback is called, so new values are added without overwriting any existing values. A potential use case would be for refreshing or reloading data in dashboards. If you'd like to learn more about partial reload functionality, please see the article here.

Figure 4: Reload