User Defined Fields

With over 1.2 million fields defined, and millions more placed onto forms, it isn’t feasible to add every possible field into the Quik! 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. These fields are named specifically by the Quik! Forms Team and use a unique formatting that are specific to the form library they are in and are intended to maintain a 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 form is called a “dealer” in our system and is assigned a DealerID. This way we know that this field always belongs specifically in the Dealer that is 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 as above, it lets our team know this field should always only 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. Using the example, “1ownPlacesTraveled” would be used if the question on the form iss asking for the first owner to list out 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 it’s initial purpose which creates complexity in both the build process and maintenance of the form.
User defined fields cannot replace existing fields that are 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 in order 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.

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 the case when new forms are added several months or even years later to a library and may be worked on by a different Forms Team member.

Since User Defined Fields are not part of our field definition, these fields 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 both building and updating forms.