Saving Forms

What this does

Let your users save a form they're working on and come back to it later with all their data still in place. Quik! handles the form regeneration. You handle the storage and the user interface that lets people find their saved forms.

The mechanism is the Save button in the Quik! Form Viewer, the UNID returned by every form generation, and your own storage of the form data between sessions.

For the underlying lifecycle and how UNIDs work, see Concepts > Form Lifecycle > Sessions and UNIDs.

When to use this

Reach for save and resume when:

• Your users routinely start forms without all the information they need (account numbers, beneficiary details, signatures from a co-owner) and need to finish later.
• Form completion rates drop because users abandon long forms.
• You want to support cross-device workflows (start on desktop, finish on mobile).
• Your workflow expects multiple sessions before a form is fully signed and submitted.

If your forms are always completed in one sitting, you don't need this. The default form viewer works without any save configuration.

Before you start

You should have:

• A working execute/html integration. See Guides > Building Forms > Launch a Form.
• An understanding of UNIDs and the session lifecycle. See Concepts > Form Lifecycle > Sessions and UNIDs.
• A place to store form data between sessions (a database, a JSON file store, or another persistent system).
• A user interface where users can see their saved forms and re-open them.

How to do it

Setting up save and resume requires four pieces. Three are on your side, one is in the API.

Step 1: Choose storage

Two options:

The default option is built in and requires no configuration. The Save button writes form data to the browser's local storage, and a Load button appears that lets the user pull it back. Data is wiped when the browser cache clears.

For production, configure the Save button to post data to your own URL. The rest of this guide covers that path.

Step 2: Configure the Save button

Set HTMLButtonSave.Show to true to display the Save button, and HTMLButtonSave.SaveURL to the URL where you want Quik! to post saved form data.

{
  "QuikFormID": "12",
  "HostFormOnQuik": true,
  "HTMLButtonSave": {
    "Name": "Save",
    "Title": "Save",
    "Show": true,
    "SaveURL": "https://your-app.example.com/quik/save"
  },
  "FormFields": [
    { "FieldName": "1own.FName", "FieldValue": "John" }
  ]
}

When the user clicks Save in the form viewer, the form posts every field name and value to your SaveURL. The Form Viewer alerts whatever response your endpoint returns, so respond with a clear success or failure message.

Step 3: Persist form data

At minimum, save these three things when your SaveURL receives a POST:

The UNID is sent as an encrypted hidden field value. You don't need to decrypt it. Store it as Quik! sent it. Pass it back exactly as is when re-launching.

Step 4: Build the saved forms UI

Your users need a way to:

• See the forms they've saved (a list, sorted by recent).
• Click into a saved form to continue working.
• Optionally, modify the package before re-opening (add or remove Form IDs).

When the user picks a saved form to continue, call execute/html again with the saved UNID and the saved form data. Quik! re-renders the form package with the prior values intact.

{
  "UNID": "5ehKj1bJHs6Ljfcyxr4OoY%2fhwymqHC8Cu5P3EVwmf4%2b1FLN0BPGWps3Ce5yfbZKJ",
  "QuikFormID": "12",
  "HostFormOnQuik": true,
  "HTMLButtonSave": {
    "Name": "Save",
    "Title": "Save",
    "Show": true,
    "SaveURL": "https://your-app.example.com/quik/save"
  },
  "FormFields": [
    { "FieldName": "1own.FName", "FieldValue": "John" }
  ]
}

Three things to know about re-launch:

• You must pass the UNID and the field data. The UNID identifies the package. The field data restores the values. The UNID alone does not carry the data.
• Re-launches do not count as new transactions against your forms usage. This is intentional. Re-opening a saved form is free.
• If a form was updated by Quik! between save and re-launch, the re-launched version reflects the latest form. The user's saved data still applies.

Common variations

Save recipient details for e-signature

By default, the Save event only includes form field data. If you want to also save the e-signature recipient configuration (so the user does not have to re-enter signer names, emails, and authentication choices on re-open), set SaveRecipientData to true:

{
  "HTMLButtonSave": {
    "Show": true,
    "SaveURL": "https://your-app.example.com/quik/save",
    "SaveRecipientData": true
  }
}

When SaveRecipientData is true, the Save payload includes an eSignData property with the configured signer information:

{
  "Recipients": [
    {
      "ID": 1,
      "SendType": "None",
      "Order": "1",
      "Name": "",
      "Mail": "",
      "IdentityCheck": 2,
      "Role": "Owner 1",
      "RoleID": "1own_0",
      "AccessCode": "",
      "ExcludedDocuments": ""
    }
  ]
}

You decide how to store and restore this object alongside the form data.

Implement a delete policy

UNIDs do not expire on Quik!'s side. Saved data lives in your storage forever unless you delete it. Some considerations:

• Decide how long to retain saved form data (the Quik! App uses 180 days as a reference).
• Build a cleanup job that deletes records past your retention window.
• Strongly encrypt saved field data at rest. Quik! encrypts individual fields and values when storing form data in its own environment.

Restore checkbox values correctly

Checkboxes need a small bit of cleanup on re-launch. The Save event stores checkbox field names with a QuikRadio<FormID> prefix (e.g., QuikRadio38002.1own.GOV.IDType). When you pass these back at re-launch time, you must strip the prefix:

Stored:    QuikRadio38002.1own.GOV.IDType
Re-launch: 1own.GOV.IDType

Without removing the prefix, the checkbox will not render as checked even though the data is preserved.

Pitfalls

• The UNID is not a substitute for the field data. When you re-launch a saved form, you must pass both the UNID and the field values back into the request. The UNID identifies the package; it does not store the values.
• Don't use browser local storage for production. It works for prototypes but it's wiped when the user clears their cache, scoped to one browser on one device, and not shareable. Configure SaveURL and persist server-side instead.
• The UNID= prefix in the form viewer DOM is not part of the UNID itself. If you read the UNID directly from the form viewer (via the hidden field QFVUNID), strip the UNID= prefix before using or storing it.
• Strip QuikRadio<FormID> from checkbox field names on re-launch. Quik!'s save event includes the prefix; the re-launch payload must not.
• Form Group Instances and duplicate forms increase complexity. When a saved package uses Form Group Instances (-1000, -2000 suffixes) or duplicate forms (-1, -2 suffixes), your re-launch must include the suffixed field names exactly as they were saved. Don't normalize them.
• Encrypt saved field data at rest. Saved form data often includes sensitive personal information (names, SSNs, account numbers, beneficiary details). Treat it as you would any other PII in your system.
• Don't expose the SaveURL endpoint to unauthenticated requests. Anyone who knows the URL could post arbitrary data there. Use whatever auth your application uses for other server-to-server endpoints.

Related articles

Continue with these articles to understand the related concepts and workflows:

• Sessions and UNIDs — Learn how Quik! identifies a saved form session.

• Launch a Form — See where saving fits into the form launch workflow.

• HTML vs PDF Execution — Understand when saving applies to interactive forms versus generated PDFs.

• Authentication — Review how authenticated requests support saving and retrieving form sessions.