On Load

From Resco's Wiki
Jump to navigation Jump to search
Rules and examples

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

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

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

Use On Load for initialization

On Load rules are the best option when it comes to handling initializations. They are designed and should be used for various steps handling actions connected to 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 which either hold or await the data. 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.

Hide email field.png

Example: Change style on Form

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

Assign style.png

Example: Empty fields are filed with placeholder

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

Placeholders.PNG

Example: Assign systemuser as owner

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

Assign systemuser.PNG

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

We created shared variable "contactCount" (integer). Then we create variable "count"(integer), where we loaded all contacts related to account by id and counted them. If variable "count" contains data its assigned to shared variable "contactCount". Shared variable can be then placed on desired form list.

px600

Used Fetch:

Contactcountfetch.PNG

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.

Rules example.png