On Load

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

Rules are client-side scripts (no-code business logic) that are executed when a user of the mobile app interacts with the app. The On Load rules are executed when you open a form or a questionnaire. Rules are managed using the rules editor, usually in Woodford.

On Load rules are available for the following user interface components:

Use On Load for initialization

On Load rules are designed and should be used for various steps handling the initialization of components or form styles. The reason for this is simple – users must wait for the On Load rule to be fully executed before they are able to see the form in the desired format. By setting up only the initialization actions in the On Load rule, its execution time is minimal (unless you are handling a great number of conditions and steps in the rule).

These are the recommended steps in On Load rules:

Hide/show fields
Enable/disable fields
Hide/show form 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 hide/show/enable/disable fields and tabs dynamically. The actions related to changes on a form while working with it are better set up in the On Change rule.

Forms

Form is a screen in the application that contains numerous fields that either hold or await the data. The default behavior of an entity form can be changed using form rules. Form rules describe sequences of steps that are executed on form-related events. On Load usually serves for handling initialization.

On Load execution

Executed right 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.

Caching forms

Form caching is a practice that reuses forms. When opening a different record, only the data is replaced; tabs that were collapsed stay collapsed, fields that were hidden remain hidden, etc. Problems may occur if you're using (poorly written) business logic that relies on the form being in the initial default state.

Warning

Always remember to add "otherwise if" condition at the end of the rule, to reset the form to default state.

Example: Hide email field

If the field Don’t Allow Emails is set to "Do Not Allow", make Email field not visible on the form.

Example: Change style on form

If the Rating belongs to category "Hot", assign "HotLead" style, otherwise set "Normal" style.

Example: Empty fields are filed with placeholder

If the street field is empty, fill each field for address with corresponding placeholder.

Example: Assign systemuser as owner

If the Owner and Created on fields are empty, assign systemuser as owner of the record.

Example: Count the number of associated contacts (for account)

We create shared variable "contactCount" (integer). Then we create variable "count"(integer), where we load all contacts related to the account through the Customer lookup field and count them. If variable "count" contains data, its assigned to shared variable "contactCount". Shared variable can be then placed on desired form list.

Used Fetch:

Questionnaires

Warning

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

On Load rules in questionnaires are often used to automatically fill in certain fields, for example, the name of the inspector or the inspection date.

Rule execution

When when you open a questionnaire.
When a repeatable group is repeated.

Example: Automatically filled fields

When a user starts new questionnaire, some of the questions are automatically filed in.

Example: Measure the duration of inspection

This rule measures the time duration of inspection. Since the rule has to contain start and end of the inspection, we need to include both On Load and On Save.

On Load part

We create a shared variable StartInspection, where we assign current time (by SetNow). We then assign this value to start-of-inspection question.

On Save part

We create a shared variable EndInspection, where we assign current time (by SetNow). We then assign this valuse to end-of-inspection question. We then create a variable var2 where we calculate timedifference between StartInspection and EndInspection (the result is set to be in minutes). In the end, we assign var2 to question inscpection.time.

Note	Questions start-of-inspection and end-of-inspection are optional. They are not required for rule to work.

Example: Access data from regarding lookup object

TBD

Example: Populate questions in questionnaire

TBD