The Save button enables users to save a form while they are working on it, leave the system for a period of time and then re-launch the form to complete it at a later time. There are many reasons customers may want to offer the ability for users to save forms while working on them. A common use case is for situations when the user does not have some form information when filling out a form, they can save the form and come back to it later when they have more information.

Open

Above: Save button in the Quik! Form Viewer

Save Options

There are two ways to use the Save button in the the Quik! Form Viewer:

• Default Functionality - save to the browser's local storage

• Configured By Customer - save back to your server

What Gets Saved

Default Functionality

The default functionality of the Save button (which includes displaying the Load button) is to save the form data to the web browser's Local Storage mechanism. Each browser has a local storage capability to save field data from HTML forms in a value-pair (field name - field value) format. This save event saves data from the form into the local browser on the user's machine only. This data can be loaded back into the form by clicking on the Load button. While the local storage option is a simple and convenient method for saving work in progress it has risks and limitations. 

What Gets Saved

The data saved into local storage includes all the field names and field values from the HTML form. 

How Long Data Persists

Data persists as long as the browser memory is not cleared, which depends on the specific settings of that browser.

How Data is Overwritten

Data is overwritten each time the user clicks the Save button or the cache memory is cleared.

Configured By Customer

Quik! provides customers with the ability to configure the Save button (which will hide the Load button) to perform the save in a manner that is consistent with their own technology, processes, security and more. 

What Gets Saved

All form field data is sent from the form to the customer's URL to save it.

How Long Data Persists

Data storage policies are up to the customer to implement and/or configure.

NOTE: The FormViewTransactionID (UNID) used to recall the saved form does not expire, however it is possible that the FormIDs could become inactivated or removed from the Quik! library.

How Data is Overwritten

Data updates are up to the customer to implement and/or configure.

Conceptual Process

To save a form you need the following components implemented:

1. Determine a location to save the form data (i.e. database)

2. Create a user interface where users can open saved forms

3. Configure the Save event in the Quik! API

4. Develop an ability to launch the saved form record

1. Determine a location to save the form data

Form data is saved though a HTTP POST to a URL where customers can receive the posted data. The data is sent the same way as any other HTTP POST event in value-pair format (field name:field value). Your URL must receive the posted data, process the info (i.e. save it) and respond to the Save event to indicate success or failure to the form viewer.

Saving form data should include the following key elements:

• The form data object - you can save the entire blob (recommended) or parse it and save individual fields (only recommended if you prefer to parse the data now vs. when the user requests the form in the future).

• The Form View Transaction ID (UNID) - needed in the Quik! Forms Engine to regenerate the form package when the user opens the form again in the future. The UNID is sent as an encrypted value. Customers can inspect the form's HTML, take the encrypted UNID hidden field, and pass it as is to the UNID property for an eventual re-launch (see step #4). The UNID does not expire.

• A saved form name - some label that helps the user identify the form package they saved (e.g. Owner Name, Account Name, Form Package Name, Save Date, etc.). It may be best to prompt the user for a custom name.

Typically this information is saved into a database record but can also be saved to an XML file, JSON file or other flat file that is easily accessible to your system.

NOTE: Consider a policy for deleting saved form records after a period of time and plan for a strong security mechanism to ensure your saved form data is secure. For example, when Quik! save forms data for customers within the Quik! environment, we parse the saved form data and uniquely encrypt each individual field and value in a non-relational manner to make it very hard to access and decipher the form data. 

2. Create a user interface where users can open saved forms

In order to open a saved form, a user needs the ability to find their saved forms, click on them and regenerate using the Quik! Forms Engine.

Below is an example of how the Quik! App (Quik!'s turnkey product) displays saved forms. This system shows the forms packages saved by the user with the most recent at the top. Each package has a custom name set by the user, and the Quik! App policy is to only keep saved forms for up to 180 days - you will need to set up your own duration policy within your system. 

When a user wants to continue working on a saved form they click the eyeball icon to launch the form immediately, or click the form record to modify the forms package (i.e. add/remove form IDs).

3. Configure the Save event in the Quik! API

Below are the Quik! Forms Engine properties required to use the Save button in your Quik! implementation:

1. Set HTMLButtonSave.Show to TRUE to show the Save button.

2. Set HTMLButtonSave.SaveURL to TRUE to set the URL location of where the saved forms will be posted.

Note: The FormViewer will alert the response from the custom SaveURL as is, no matter if the request is successful or not.

4. Develop an ability to re-launch the saved form record

Call the Execute method when a user clicks some sort of "re-launch" button in the UI built in Step #2. Keep in mind, when an HTML form has been generated, a UNID is generated and output to the HTML as a hidden field (which is posted in the Save event). This very same value is also populated in the UNID Quik! Forms Engine property, which is available after the Execute method.

Note: If a form ID has been updated and published by Quik! between the Save event and the re-launch event, then the re-launched form will reflect the latest version of the form, with all previously entered data intact.

Important:

• When re-launching a saved form, the UNID property must be passed to the Quik! Forms Engine, and will have the value that is output to the form as well. The reason for re-launching with the UNID is that the Quik! Forms Engine understands that the customer is regenerating a previously saved form package, and therefore it will not be counted as a transaction towards forms usage.

• You will need to include all field data when re-launching the form, as passing in the UNID does not carry that information over.

• When populating checkboxes with saved data, it is imperative that customers remove the "QuikRadio<Form ID #>" prefix from the FieldName value. While the Quik! save routine includes this prefix in checkbox field names, it needs to be removed in order for the checkbox check to render on the re-launched form.