User Defined Fields

With over 1.2 million fields defined and millions more placed onto forms, adding every possible field into the Quik! isn't feasible. Field Definition and maintain them as Standard or Premium fields. With that being said, we know there are times when a customer needs several undefined fields to be static and maintained from version to version on a form.

To solve this situation, Quik! has designed User-Defined Fields that are essentially Premium Fields on the fly. The Quik! explicitly names these fields. Forms Team and use unique formatting specific to the form library they are in. They are intended to maintain similar formatting to our Standard Field Names. Our Forms Team will maintain these fields from version to version on the same form to ensure that no mapping validations for the customer will ever break on that specific form.

Breaking down a User Defined Field:

For example, using the user-defined field name of “User.D123.1ownPlacesTraveled”

All User-defined fields will always start with “User.”
The second part of the field name, “D123,” represents the DealerID in our system. Every company that gives us a form is called a “dealer” in our system and is assigned a DealerID. This way, we know that this field always belongs specifically to the Dealer assigned to that DealerID.
- In some cases, we’ll use “F45542,” where the “F” represents “Form,” and 45542 is the FormID in our system. Similar to the above, this tells our team that this field should always be on FormID 45542 in our system.
The last part of the User-Defined Field name will be targeted around the specific purpose of the field. For example, “1ownPlacesTraveled” would be used if the form asks for the first owner to list all places traveled.

Potential issue with User Defined Fields:

User-defined fields must serve a singular purpose: Customers often ask for a field to do more than its initial purpose, which creates complexity in the build process and maintenance of the form.
User-defined fields cannot replace existing fields: defined by the Quik! Field Definition.
Forms cannot be majority built with user defined fields: Some customers may ask us to build user-defined fields on every non-defined field in the form to create 100% field mapping on that form. While technically possible, adding this many user defined fields to the form creates a custom field mapping that is very difficult to maintain and sets the wrong precedent for future forms being added to the library. It is better to add definitions to the Quik! Field Definition as part of an existing definition or as a custom definition for a particular industry or customer.
User-defined fields are defined by the Quik! team only: The naming convention that Quik! chooses for a user-defined field serves many purposes for the Quik! Forms Build Team, including efficiency and speed in building and maintaining forms. As a result, Quik! cannot promise to adhere to specific customer field name requests.

Important Note:

As you can imagine, if a forms library requires hundreds or even thousands of fields to be mapped using User Defined Fields, it can become quite challenging for our Forms Team to maintain as they aren’t accustomed to every one of those fields as they would for a standard field such as 1own.FullName.

This is especially true when new forms are added to a library several months or even years later and may be worked on by a different Forms Team member.

Since User-Defined Fields are not part of our field definition, they do not appear in our forms tools, and therefore, it is very difficult and inefficient for the Quik! Forms Team to share user-defined fields across forms.

Be aware that requests for user-defined fields can result in additional costs for customizing forms and delays in building and updating forms.