Form rules

Rules and examples
On Load On Change On Save On Create Select Form Row Script On Execute On Can Execute Cell Click Button Click On Item Added On Item Completed On Repeat On Delete Form rules Rules on the bulk update form Command rules Questionnaire Designer examples Rules editor Global constants

Warning

Work in progress! We are in the process of updating the information on this page. Subject to change.

Form is a screen in the application that contains numerous fields which either hold or await the data. It is a tool that enables system administrators to represent the database data and collect user data in a user-friendly way. Default behavior of an entity form can be changed using form rules, which control form events and provide actions that can take place if one of the events occurs.

Lifecycle of Entity Form & Entity Form events

Default behavior of an entity form can be changed using form rules, which control form events and provide actions that can take place if one of the events occurs. Form event is an action of a user or code, which invokes response action from the entity form. The main three events are:

Load: Occurs before the form is displayed on the screen. It occurs immediately after the user chooses to open an entity record from the List view screen. On Load rule connected to a Load event is activated on Load itself.
Change: Occurs after the form has been displayed on the screen and any change on it is recognized. OnChange rule connected to a Change event is activated on Change and Load events as well.
Save: Occurs after the form has been displayed on the screen, user hits the save button and the form is trying to get closed (off the screen). OnSave rule connected to a Save event is activated on Save itself.

Note	After the form is displayed on the screen, a Change event occurs as loading data into each field on entity form is considered a change of those fields. Therefore, On Change rules are triggered.

Best practices for form rules to keep in mind

In the following section, we go through some of the best practices which you should apply in your project.

Use On Load rule only for initialization handling actions

OnLoad rules are the best option when it comes to handling initializations. Users must wait for On Load rule to be fully executed before they are able to see the form in a desired format. By setting up only the initialization actions in On Load rule, its execution time is minimal.

Set up in OnLoad rule:

Hide/Show fields
Enable/Disable fields
Hide/Show tabs
Assign styles to fields or to the entire form
Automatically assign values to fields, e.g. date & time, location, company number etc.

Do not set up in OnLoad rule:

Hide/Show/Enable/Disable fields and tabs dynamically. The actions related to changes on a form while working with it are better to set up in the On Change rule.

Using the “otherwise if” part of the rule

One of the most common mistakes when setting up form rules is skipping the “otherwise if” part of the rule.

Keep in mind that the form is reused while the application is running. What does this mean? If you set a style of a field by rule, without defining the “otherwise if” part, the style of the field on the form is saved. Afterwards, when you open a new form of the same entity, it simply uses the style you saved on the last one. Without using the “otherwise if” part of the rule to change the style back, the form is simply reused.

Example:Change the color of the form field (city)

For the Load event create an OnLoad rule which checks if the field contains data. If it does, you assign “greyFieldStyle” to that field. You don’t specify any “otherwise if” part, because the rule seems straightforward.

You open the form for the first time and its background is white, because the city is not filled. So we add a value to the City field and save the form. When re-opening the form, the city field is grey because it already contains data.