Model-driven forms are how detailed data for a row is presented to the user during editing and viewing. Forms provide a structured way to represent the data when it's 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 lay out 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 won't be visible to users until the form is saved and published.
Forms are organized into header, body, and footer, each capable of containing form elements like columns. 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 logical grouping of data can make a more usable experience because the user isn't constantly tabbing around to find things.
Standard column Controls
The most common task you'll perform when editing a form is placing column controls on the form. A column 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, and other properties like visibility and read only. Without special configuration, a column will render with a control automatically selected by the runtime that is appropriate for the data type of the column. For example, an Option Set column will show the data in a drop-down list.
The following shows an example of the column properties that can be edited on each column control.
Depending on the column type, the column might offer other settings that can be changed. For example, a Lookup column will allow you to set the default view and other view-related options.
Custom controls let you transform columns that traditionally contain text into visualizations. 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 rows. Custom controls can appear as visualizations 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 input custom control for a column in web browser clients and a slider custom control for the phone app. After the customization 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 column on a form.
The following is an example showing on the Controls tab on column properties how you can configure a custom control.
The data type of the column determines what custom controls are available. Examples of custom controls include:
In addition to column-related data, you can also configure many specialized 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 specialized section that can be added to main forms that offers interaction with related data in the context of the hosting table row. Subgrids display a list of rows or charts. The Quick View control displays data from a row 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, columns, 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 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 don't 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:
|Form||OnLoad||Occurs when the form loads.|
|Form||OnSave||Occurs when data is saved.|
|Tab||TabStateChange||Occurs when the tab is expanded or collapsed.|
|Column||OnChange||Occurs when data in the column changes and the control loses focus.|
|iFrame||OnReadyStateComplete||Occurs when the content of an iFrame loads.|
Most of the time developers create the event handlers; however, you might want to review what is configured on a form.