On Load

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:

• Forms
• Questionnaires

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 filled with placeholder

If the street field is empty, fill each field for the address with the 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 the 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". The shared variable can then be placed on desired form list.

Used Fetch:

Example: Expand Contact Tab (on account), if associated contacts found

We create a variable where we fetch all contacts associated to the customer (Account). If this variable contains data (records found), Contact tab on the form is expanded. Else if the variable is empty (no records found), the Contact tab is not expanded.

Used Fetch:

Example: Create a Task on the form through an unrelated entity list on event entity

In this rule, we want to create a Task from the event entity (Order in this case) and automatically fill in the regarding field with the customer id.

First, we add an unrelated Task list to the Order form.

We have to edit the Task list filter to see only tasks regarding current Order customer. Used Filter:

If the Task is new and relationship.target (where was the task creation initiated), type salesorder, load reference from this relationship.target -> Salesorder into a variable, and assign it to the Regarding field.

Questionnaires

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: Populate the questions with data from regarding lookup entity

Regarding lookup is a special component. When you open the questionnaire from an entity record, it is automatically filled with the record id. This way, we can set up a rule that automatically fills in questions from the regarding lookup entity (Appointment in this case).

We create a shared variable, where we want to store the appointment record. If question.resco_regardingid.value (regarding lookup) contains data and is of type appointment (comes from appointment), assign its value to appointmentRecord. If the appointmentRecord contains data, we can fill the data into the questions.

Optionally, you can go further and access data from appointment regarding entity (Account in this case). Instead of filling questions with appointment record fields, create a string variable where we load appointment id. In the next variable we fetch account regarding appointment, where the id is equal. If the variable (regarding account) contains data, we can fill in the questions with data inside.

Used Fetch:

Example: Populate the questions with data from regarding lookup entity 2

Similarly, as in previous example, we want to populate question with regarding lookup entity data. In this example, we want to populate root questions and two question groups in the questionnaire. This means we have to specify On Load rules for each question group. For the following rules we use three shared variables:

We start with root questions where we want to load data from regarding lookup entity (workorder/workorderschedule).

Root questions: If regardingid.value (lookup) contains data and is type of workorderschedule, we create a variable where we loadreference from workorderschedule. If this variable contains data, we assign workorderid to shared variable OriginalWO and work-order-number. Else if regarding.value contains data and is type of workorder, we can assign it directly to OriginalWO and work-order-number.

Customer information questions: If the root question work-order-number and OriginalWO contains data, we assign OriginalWO.customerid to customer.name question and shared variable Customer. From then on, we fill the customer information questions from shared variable Customer (primary contact, address.

Equipment information questions: Same as in previous question group, we assign assetid from OriginalWO to equipment and shared variable Asset. From shared variable Asset we then fill the rest of equipment questions.

Note	In addition, if the access to the questionnaire is only possible through workorderschedule or workorder, we can disable fields that are filled automatically and should not change (like work-order-number, customer name).