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: Assing currency from entity user

If the entity isNew equals true, create variable user, where we load reference from entity user.Owner --> systemuser. Clear the currency field and assign the value transactioncurrency field from the variable user.

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:

To see the rule execution in the app, click here.

Example: Populate fields of the new Task record created on the list of another entity (Relationship.target)

In this example, we want to create a Task through the task list on the Order form and automatically fill in the regarding field with the customer id.

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

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.

To see the rule execution in the app, click here.

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 the inspection. Since the rule has to contain the 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 the current time (by SetNow). We then assign this value to the start-of-inspection question.

On Save part

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

Note	Questions start-of-inspection and end-of-inspection are optional. They are not required for the 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 the 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.

To see the rule execution in the app, click here.

Optionally, instead of filling questions with appointment record fields, we can go even further and use regarding entity of Appointment. Create a string variable where we load the appointment id. In the following variable we fetch an 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 question group: If the root question work-order-number and shared variable 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 question group: 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.

To see the rule execution in the app, click here.

Note	In addition, if initiation of the questionnaire is only possible through workorderschedule or workorder (or any entity), we can disable questions (set them as not editable) that are automatically populated from them (like work-order-number, customer name).

{{#CI form: title = Was this information helpful? How can we improve? | type = inputs | [textarea] }}