Form rules

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.

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.

Then, you add a new record and open a new form. What happens? The City field is grey even though it doesn’t contain any data.

That’s because there is no “otherwise if” part of the rule specified, which would change the style back to white color if the field is empty. The rule itself is not reset every time a form is closed. That is why you have to set On Load to change the City field color back to white, if it does not contain data (in this case set the style back to Normal).