Customizing the Form UI

When Quik! renders a form as HTML, you control the experience your end users see — which buttons appear and what they do, the branding on the form, and which documents and fields a user can view or edit. This guide covers buttons, logos, background colors, cover pages, document visibility, and read-only/locked fields.

What you can customize

The rendered HTML form is configured through properties you send in the Quik! Forms Engine execute/html request. The main areas of control are:

• Buttons — the Submit, Sign, Email, Save, Load, Print, Reset, and Clear buttons in the form's top menu.
• Branding — the company logo (static or dynamic per user), field background colors, and an optional PDF cover page.
• Visibility & read-only — restricting which forms a signer receives in an e-signature envelope, and locking fields or whole forms against editing.

Some of these are configured at runtime through API properties; a few (the static logo, the cover page) involve setup with the Quik! forms team or your Quik! Customer Central account. Each section below calls out which applies.

Buttons

In QuikFormsEngine v5.5, every button is configured through its own object under the top-level request, grouping each button's settings into a single structure. Every button object shares the same four base properties, plus button-specific properties where noted.

Common button properties

Available buttons

Example: showing buttons

{
  "HTMLButtonClear": {
    "show": true,
    "title": "Clear all fields of form data.",
    "name": "Clear"
  },
  "HTMLButtonSubmit": {
    "title": "Submit",
    "submitContentType": "Json",
    "show": true,
    "name": "Submit",
    "submitURL": "https://my.domain/submit",
    "SubmitJavascript": "alert('custom javascript!');"
  },
  "HTMLButtonSave": {
    "SaveURL": "https://my.domain/save",
    "SaveJavascript": "alert('custom javascript!');",
    "Show": true,
    "Title": "Save form data so you can come back to it later.",
    "Name": "Save"
  }
}

The Save button

The Save button lets a user save a form in progress, leave, and re-launch it later to finish. There are two modes:

Default — save to the browser. If you do not set SaveURL, the Save button writes all field names and values to the browser's local storage as value pairs, and the Load button is shown so the user can restore them. Data persists as long as the browser's memory is not cleared (which depends on the browser's settings) and is overwritten each time the user clicks Save or the cache is cleared. This is simple but carries risks and limitations.

Configured — save to your server. Set SaveURL to post all form data to your own endpoint instead. This hides the Load button, because restoring saved data becomes your responsibility. Your URL must receive the POST, persist the data, and return a response (which the Form Viewer alerts to the user as-is, whether the save succeeded or not).

To save to your server you implement four things: a place to store the data, a UI where users find their saved forms, the Save event configuration above, and a way to re-launch a saved package. When you persist a saved form, store:

• The form data object (saving the entire blob is recommended over parsing individual fields).
• The Form View Transaction ID (UNID) — output to the HTML as an encrypted hidden field and posted in the Save event. You need it to regenerate the package later. The UNID does not expire.
• A human-readable saved-form name to help the user identify the package.

To re-launch a saved package, call the Execute method with the saved UNID. Passing the UNID tells the engine this is a regeneration, so it does not count as a new forms-usage transaction. Note:

• You must pass the UNID and re-supply all field data — the UNID alone does not carry field values back.
• When populating checkboxes from saved data, remove the QuikRadio<Form ID #> prefix from each FieldName; the save routine includes this prefix, but it must be removed for the checkbox to render checked on re-launch.
• If Quik! published an updated version of a form between the Save and the re-launch, the re-launched form reflects the latest version with previously entered data intact.

Saving e-signature recipient details. The Save event can optionally include an eSignData object containing recipient information from the e-signature process, so you can restore it on re-launch. It is not included unless you explicitly opt in by setting SaveRecipientData to true in HTMLButtonSave (default is false).

{
  "QuikFormID": "12",
  "HostFormOnQuik": false,
  "HTMLButtonSave": {
    "Name": "Save",
    "Title": "Save",
    "Show": true,
    "SaveURL": "{{YOUR_SAVE_URL}}",
    "SaveRecipientData": true
  }
}

The Submit button

A Submit event posts form data to a URL you specify, much like a Save event — the key difference is that Submit always validates any Required Fields first. Configure it by setting HTMLButtonSubmit.Show to true and providing HTMLButtonSubmit.SubmitURL.

By default the posted data is value-pair format; change it with SubmitContentType, which accepts Json or UrlEncoded.

{
  "HostFormOnQuik": true,
  "QuikFormID": "12,441",
  "SaveSubmitCombined": false,
  "HTMLButtonSubmit": {
    "title": "Submit",
    "submitContentType": "Json",
    "show": true,
    "name": "Submit",
    "submitURL": "string"
  },
  "FormFields": []
}

A few combination behaviors are worth knowing:

• SaveSubmitCombined — defaults to true, meaning the Submit button first triggers the configured SaveURL (if any), then the SubmitURL. Set it to false to fire only the Submit.
• SignSubmitCombined — set to true to make the Submit event fire when the Sign button is clicked, so form data is validated and posted to your SubmitURL before the e-signature pop-up opens. This is useful for storing or validating data before signing, when fields become uneditable.

Custom submission handling. Set SubmitJavascript to run your own logic (for example an AJAX POST) instead of the default behavior — configuring it overrides Quik!'s default submit entirely. If you need to keep the standard submit payload formatting (for example to reuse the payload with the Print endpoint) and add custom logic, use CustomJavascript instead, which preserves the standard Quik! submit behavior. A common pattern parses the server's JSON response and alerts the user based on an ErrorCode ("0" for success, "1" for failure) and ErrorMessage.

Branding

The company logo (static)

You can set the logo shown on your forms either programmatically or through your Quik! Customer Central account.

Programmatically, two properties control the logo:

Through the account UI, log in to Quik! Customer Central (qcc.quikforms.com), open the Quik! Forms Enterprise Manager, go to Configure Settings, and either upload an image for Quik! to host or supply a URL to your own hosted image. Click Save when done.

For all methods, to avoid stretching or warping, your logo should be 150 px wide by 65 px high. Accepted formats are JPG, GIF, and PNG.

Dynamic logos (per user)

If different users in your organization need their own logo on the same library of forms, use dynamic logos. The logo becomes a field you populate at generation time, like any other field.

How it works:

1. Each form that needs a custom image must be built by the Quik! forms team with a dedicated image field at the desired size and location. The field name format is Image.User.File.{QuikFormID}.{FieldInstanceID}.
2. You host each image at an HTTPS (SSL) URL.
3. When generating the form, supply that field name with the image URL as its value.

{
  "HostFormOnQuik": true,
  "QuikFormID": "12345",
  "FormFields": [
    {
      "FieldName": "Image.User.File.12345.1",
      "FieldValue": "https://mycompany.com/images/logo1.png"
    }
  ]
}

Image files must be PNG, JPG, or GIF, hosted by you, and served over HTTPS. Contact Quik! to enable the feature, and provide the logo field's size (width and height in pixels) and placement (page number and coordinates) — or, instead, a screenshot or a PDF copy showing the desired placement.

Field background colors

You can set a field's background color two ways:

• Field rules — configure it as a field rule in the QFEManager site (see Configuring Field Rules).
• Per field at runtime — set the field's FieldBackgroundColor to a hex value. In REST, this is an attribute on each object in the FormFields array of your execute/html request; the property name is FieldBackgroundColor (the same casing as the .NET AddFieldToForm method). Accepted values are hex codes such as "#FF0000", "#AABBCC", or "#CCC".

{
  "QuikFormID": "12345",
  "FormFields": [
    {
      "FieldName": "1own.M.City",
      "FieldBackgroundColor": "#FF0000"
    }
  ]
}

The same attribute is available through the .NET AddFieldToForm method by setting FieldBackgroundColor on the FormField object:

// C#
objQFE.AddFieldToForm(new FormField {
    FieldName = "1own.M.City",
    FieldBackgroundColor = "#FF0000"
});

' VB.NET
objQFE.AddFieldToForm(New FormField() With {
    .FieldName = "1own.M.City",
    .FieldBackgroundColor = "#FF0000"
})

To restore the default color, omit the FieldBackgroundColor attribute entirely.

Cover pages

A cover page is a single Form ID that Quik! inserts into your package automatically — but only when printing a PDF. It is commonly used to enable scanning of printed documents. The cover page is not sent to e-sign vendors and is not displayed in the HTML form to users. It generates for every form view transaction and cannot be bypassed at runtime.

Cover pages are set up by the Quik! forms team once your forms library is configured — there is no runtime property to add one. Work with the forms team to create a cover page for your forms.

Visibility & read-only

Document visibility (per signer)

By default, every signer in an e-signature envelope receives all forms in the package. Document Visibility lets you restrict which forms a given signer receives — for example, sending a custodian only their own forms while the client still receives and signs all of them. In Quik! this is done by "excluding" forms by role.

Requirements:

• Your DocuSign account must have Document Visibility enabled.
• In the ESignType section of your execute/html request, set both SignMultipleDocs and EnforceSignerVisibility to true.

You exclude forms with either of these properties, used independently or together:

You cannot exclude a document from a signer who has fields on that document.

{
  "QuikFormID": "38002,218",
  "ESignType": {
    "Type": "Docusign",
    "AuthUserID": "{{YourAuthUserID}}",
    "SignCallBackURL": "{{YourSignCallBackURL}}",
    "SignEnvironmentID": "{{YourSignEnvironment}}",
    "SignMultipleDocs": true,
    "EnforceSignerVisibility": true,
    "Recipients": {
      "Signers": [
        {
          "Role": "1osj",
          "ExcludedDocuments": [38002]
        }
      ]
    }
  }
}

You can also exclude documents from carbon-copy recipients via ExtraRecipients (each with its own ExcludedDocuments or ExcludedLibraries). When excluding documents, configure a custom SignMessage — by default the sign message lists all forms, including excluded ones.

Read-only / locked fields

You can control which fields a user can edit at several levels:

Read-only attributes can also be carried to DocuSign so fields are presented appropriately in the signing experience.

In every case, read-only is expressed with the FieldReadOnly value, an enum: -1 (NotSet), 0 (NoRestrictions), 1 (Read_Only).

Locking a single field

To lock one field while leaving the rest editable, set FieldReadOnly to 1 on that field. In REST, this is an attribute on the field's object in the FormFields array of your execute/html request:

{
  "QuikFormID": "12345",
  "FormFields": [
    {
      "FieldName": "1own.FName",
      "FieldReadOnly": 1
    }
  ]
}

The same attribute is available through the .NET AddFieldToForm method (set FieldReadOnly on the FormField object). To set many fields that share a partial field name at once — for example every FName field — use the SetFieldPropertyByFieldName method with a FieldPropertiesInBulkByFieldName object (FieldName plus FieldReadOnly).

Locking all fields for a role

To lock every field belonging to a role in a single call, use the SetFieldPropertyByRole method. Pass a FieldPropertiesInBulkByRole object with the RoleName (e.g. 1own) and FieldReadOnly set to Read_Only. The method covers all fields whose name contains that role (1own.FName, 1own.MName, 1own.Addr123, and so on).

' VB.NET
Dim fieldProperties As New FieldPropertiesInBulkByRole() With {
    .RoleName = "1own",
    .FieldReadOnly = QFD.FieldReadOnly.Read_Only
}
objQFE.SetFieldPropertyByRole(fieldProperties)

Locking specific forms in a bundle

SetFormReadOnlyFormIDs sets specific forms in a bundle as read-only while leaving others editable. It takes a list of Form IDs (including instance suffixes when Form Group Instances are involved) and must be used with SetFormReadOnly — set SetFormReadOnly to true first, then list the read-only Form IDs.

{
  "HostFormOnQuik": true,
  "QuikFormID": "38002,25525,25524,38002-38002,38002",
  "SetFormReadOnly": true,
  "SetFormReadOnlyFormIDs": ["25524", "38002-1", "38002-1001"]
}

In this bundle (which uses two Form Group Instances): in the first group, Form 25524 and the second instance of Form 38002 are read-only; in the second group, only the second instance of Form 38002 is read-only.

Related articles

• HTML vs. PDF Execution
• Launch a Form
• Configuring the Submit Button
• Grouping and Bundling
• Send Direct to DocuSign