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

...

  1. user flow, customer calls the /forms/roles/client REST

...

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

...

  1. "2ben" for the second beneficiary

...

  1. , etc.) on the given set of selected Form IDs to the user

...

  1. 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

  2. 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

...

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

Helpful Links