Fields and Field Names

What it is

The Quik! Field Definition is a shared vocabulary of field names used across every form Quik! builds. Over 1.2 million fields are defined today. When you send data to a Quik! form, you reference fields by these names. The same field name on different forms maps to the same kind of value, regardless of how the form is visually designed.

Why it matters

Forms in financial services repeat the same information constantly: name, address, account type, signature. Without a shared vocabulary, every form would have its own field names and you would re-map your data for every new form you wanted to prefill.

The Field Definition solves that. Build your integration once against the standard names, and any form built to the standard accepts your data without per-form mapping work.

How it works

Service levels

Every Quik! form is built to one of three service levels. The service level determines how much automation the form supports.

If you are integrating against the public form library, you are working with Standard and Premium fields.

Field name structure

Field names use a dotted hierarchy that reads left to right from broadest to most specific. Three common patterns:

Examples of each segment:

• Role prefix (1own, 2own, 1rep, 1ben): identifies which person or entity the field belongs to. The full role prefix vocabulary is in the Roles and Role Prefixes article.
• Attribute (FName, Email, Sign, FullName): the specific value the field holds.
• Middle segments (when present) scope the attribute. For example, the second segment in 1own.H.Email distinguishes one kind of email from another when the form supports multiple variants. The set of valid middle segments is documented in the Field Definition Reference.

Three kinds of field names you will see

Standard or Premium fields. Defined and maintained by Quik!. Stable across form versions. These are what most integrations map to. Example: 1own.FullName, 1own.H.Email.

User-Defined Fields. Custom fields the Quik! Forms Team creates for a specific customer or form when a field is too unusual to add to the public Field Definition. They are stable from version to version on the same form, but they cannot replace existing standard fields, must serve a singular purpose, and can add cost and delay to form builds.

User-Defined Field names follow a specific format:

User.D123.1ownPlacesTraveled

Generic fields. Placeholder names auto-generated when a field on a form does not match any field in the Quik! Field Definition. They use a random format like NFSVC2349.txt1.01 (text) or NFSVC2349.chk1.01 (checkbox). Generic field names can change in future form updates. Do not map to them on public library forms.

The Field Definition Reference

The complete list of field names, their data types, and the attributes available for each role lives in the Quik! Field Definition Reference. Use the Reference when you need to look up the canonical name for a specific data point, or to confirm whether a field is Standard or Premium.

For developers: where this shows up in the API

This section is for the technical reader implementing the integration.

• FieldName property in the FormFields array when calling execute/html or execute/pdf. This is where you supply the Field Definition field name.
• AddFieldToForm method: sets a single field value at runtime.
• LoadXML method: bulk-sets fields from an XML payload.
• /forms/fields endpoint (REST QFEM v2000): returns the full list of field names for a given set of FormIDs. Use this when you need to know what fields are available on a form before integrating.
• TestDataMode property (set to true): generates the form with each field populated by its own field name. Fastest way to see field names visually on a form. Checkbox and formatted fields (SSN, Phone) are not labeled by this method.

Pitfalls

• Do not map to Generic field names on public library forms. They are not part of the Field Definition and may change without notice. If you need stable field names on a form that has Generic fields, add a copy of the form to your private library so the field names are under your control.
• Strip the QuikRadio<FormID> prefix from checkbox and radio field names when prefilling. Inspecting a checkbox in the browser shows something like QuikRadio5653.1acc.RegType, but the value you supply to the API should be 1acc.RegType.
• User-Defined Fields are defined by the Quik! Forms Team, not by you. Quik! controls the naming convention. Bulk requests for User-Defined Fields can result in additional cost and longer build times.
• Checkbox and radio fields use both a name and a value. The value (for example "57") is the export value of the option, not free text. Prefilling a checkbox means setting its field to the matching export value.

Related articles

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

• Roles and Role Prefixes — Learn how Quik! identifies which person or entity each field belongs to.

• Form Groups and Instances — Understand how field names change when one package includes duplicate forms or separate data sets.

• Field Mapping — See how to map customer data to the correct Quik! fields before launching a form.

• Field Rules — Learn how field behavior can change based on form logic and customer input.