Forms Elements

In the last step, we went through an overview of Model-driven Forms, now let’s explore Forms Elements.

Model-driven forms are how detailed data for a record is presented to the user during editing and viewing. Forms provide a structured way to represent the data when it is rendered for interaction with the user.

Forms abstract the form creator from the exact rendering specifics required to transform the form definition you create for the user’s device size and capabilities. However, when you layout the form using some knowledge of the current form rendering engine it will help you make more usable forms. Unified Interface is the current name of the framework that renders the form definitions for the user.

When editing forms, the changes will not be visible to users until the form is saved and also published.

Forms are organised into header, body and footer, each capable of containing form elements like fields. The body of the form is further structured with areas called tabs that contain sections. Tabs and sections can be configured to support columns of form elements giving further structure to the content. The first tab on a form is the most important and should contain the priority data the user should see. While you could configure many tabs, keeping it to a smaller number with a logical grouping of data can make a more usable experience because the user is not constantly tabbing around to find things.

Form Elements

Standard Field Controls

The most common task you will perform when editing a form is placing field controls on the form. A field can be added to the form multiple times if needed, the value shown will be the same for each occurrence. Each control you place on the form you can control the label shown, as well as other properties like visibility and read-only. Without special configuration, a field will render with a control automatically selected by the runtime that is appropriate for the data type of the field. For example, an Option Set field will show the data in a drop-down list.

The following shows an example of the field properties that can be edited on each field control.

Custom Controls

Custom controls let you transform fields that traditionally contain text into visualisations. Similarly, you can use custom controls to transform datasets, such as a view, to display in a more visual rendering rather than a list of records. Custom controls can appear as visualisations on forms, dashboards, views, and homepage grids. You can set one type of custom control to appear in the web browser client while having a different custom control appear in the phone or tablet mobile apps. For example, you could use a number of input custom control for a field in web browser clients and a slider custom control for the phone app. After the customisation is published, users can fully interact with the control to change the value, such as by sliding the control when using the linear slider custom control. Changes are automatically saved when the form is closed just as they are when the user changes a traditional field on a form.

The following is an example showing on the Controls tab on field properties how you can configure a custom control.

The data type of the field determines what custom controls are available. Examples of custom controls include:

Option Set

Flip Switch

Linear Slider

Radial Knob

Star Rating

Number Input

Specialised Controls

In addition to field-related data, you can also configure several specialised controls for use on the form. These controls can provide a unique view of data or access to a service like mapping. A Reference panel is a specialised section that can be added to main forms that offer interaction with related data in the context of the hosting entity record. Sub-grids display a list of records or charts. The Quick View control displays data from a record that is selected in a lookup on the form – for example, on the account form you might want to display all the details of the primary contact inline on the Account form. More generically, adding iFrames to a form will integrate content from another website within a form.

Show or Hide Form Elements

Several types of form elements have the option to be shown or hidden by default. Tabs, sections, fields, iFrames, and web resources all provide this option. Using form scripts or business rules, the visibility of these elements can be controlled to create a dynamic form to provide a user interface that adapts to conditions in the form.

Rather than designing forms that depend on scripts to control the visibility of options, consider whether a business rule or switching to a different form may be better suited to meet your requirements. If you do use scripts, make sure that any element that might be hidden is hidden by default. Only show it with scripts when your logic calls for it. This way it will not be displayed in presentations that do not support scripts.

Form Event Handlers

Form event handlers allow configuring developer logic that runs when the user interacts with the form.

Form event handlers for forms can be configured for the following areas in a form:

An event handler consists of a reference to a JavaScript web resource and a function defined within that web resource that will execute when the event occurs. Each element can have up to 50 separate event handlers configured.

Most of the time developers create the event handlers however, you might want to review what is configured on a form.

Next up, we’ll be finding out more about Configure Multiple Forms.