Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

Background

While the Quik! Forms Engine is the primary way in which Quik! delivers

...

 forms, the Quik! Field Definition is the power behind how

...

we manage

...

 them. The purpose of the Field Definition is to make all forms and documents work in the same manner through a defined set of field types with common field names. In order to prefill forms, customers will need to first map fields in their data source system (typically a CRM) to the Quik! field definition. This mapping should only be performed once on initial setup, followed by minor updates as new fields are added. Whether a given form's job is to open a new account or change an address, any time the form requires mapped field information (such as the customer's first and last name), that name should appear on the form in the correct place regardless of how the form is visually designed.

Field Mapping Configurations

Our intent is to simplify how customers talk to Quik! via field mapping, and reduce the amount of work required as much as possible. When prefilling a form, it is only required that the customer tell Quik! a field name and value. We usually recommend customers take the "shotgun approach" - send all of a client's data to a form for prefill, and the form will apply what is needed on the given fields and ignore everything else.

A typical process for configuring field mapping back-end and UX looks like this:

  1. Customer builds a translation table that relates Quik!'s base field name (e.g. "FName" is the Quik! definition for a client's first name field) with corresponding field as it exists in customer's data source (e.g. "FirstName" or however their database defines a first name field).

  2. At the appropriate point in the customer's

  3. UX in
  4. user flow, customer calls the /forms/roles/client REST

  5. method
  6. method in real time to get and display all of the client roles (e.g. "1own" for owner 1,

  7. or
  8. "2ben" for the second beneficiary

  9. number 2
  10. , etc.) on the given set of selected Form IDs to the user

  11. User
  12. Either the user manually assigns clients to the roles they will populate on the forms, or customer’s system auto-assigns people to roles based on some logic

  13. When it's time to generate the forms, customer's system will query their translation table and prepend every Quik! role to the base field name, loop through all base field records for each client, and populate the form using the AddFieldToForm

  14. method
  15. Method and the corresponding properties. This will result in a form with prefilled client data.

Helpful Links

  • The Quik! Field Definition Guide

    The purpose of the Quik! Field Definition is to make all forms and documents work in the same manner through a defined set of field types with common field names. 

    For an in-depth look at the Quik! Field Definition, naming conventions, and

    a list

    tables of all Quik! fields and checkbox values,

    please How to find field names on a form

    visit the Quik! Field Definition Guide linked above.

    Consulting this guide has proven immensely helpful for customers when setting up field mapping for their implementation.


  • Where Can I Find Field Names & Values on a Form?
    There are a number of ways to see what fields and checkbox values exist on a form. Check out the link above for more information.