Rules editor

Rules are the most important tool for adding business logic to your Resco Mobile CRM app. Rules are scripts that are performed when a user of the mobile app opens a new view or form, taps a button or record, modifies any value, etc. You can modify many things using the scripts, most notably you change data or change the UI.

Various rules can be defined for each of the user interface components, such as form or view. They are usually edited in Woodford, but other standalone tools, like the Questionnaire Designer also allow working with rules.

Actions that trigger rule execution

When you edit a UI component in Woodford, you can define actions that trigger rule execution.

(*) Applies to editable views.

Starting the rules editor

Forms and views:

1. Edit an app project in Woodford.

2. Select an entity from the Project menu and click Show UI.

3. Edit a form or view.

4. Click one of the rule buttons available in the toolbar.

Route plan:

1. Edit an app project in Woodford.

2. Select Route Plan from the Project menu.

3. Edit a route plan.

4. Click On Item Added or On Item Completed.

   • If you don't see the buttons, uncheck the option View-only Mode.

Calendar:

1. Edit an app project in Woodford.

2. Select Calendar from the Project menu.

3. Edit a calendar and go to the Rules tab.

4. Select an entity and click Edit Rule.

Questionnaire Designer:

1. Edit a questionnaire template in the designer.

2. Click one of the rule buttons available in the toolbar.

Schedule Board:

1. Edit an app project in Woodford.

2. Select Scheduler from the Project menu.

3. Edit a scheduler, then click On Create or On Change.

Report Designer:

1. Edit a report template in the designer.

2. Select either the report body or a repeater.

3. Click Edit Sources to display a list of variables defined for that component.

4. Select any variable and click On Create.

Using the editor

The following functions are available when editing rules.

Save, Save & Close

Save your changes.

Syntax Check

Check if the script workflow is valid. Invalid scripts cannot be saved.

Disable Rule, Enable Rule

Temporarily disable a rule, until you turn it back on. To permanently disable a rule, delete it.

Disable/Enable acts on the entire rule set for the trigger being edited (e.g. all On Load rules for that form), not just the individual script currently open in the editor.

Edit functions

Common functions, such as Copy or Delete, help you work with longer scripts effectively.

Step

Add a step. Steps do things, for example modify data or user interface.

Say Text and Show Toast

Display a text message to the user: a combination of static text and a variable. Say Text is a pop-up window that requires the user to confirm; Show Toast disappears after a few seconds on its own.
Tip: you can use these steps for simple debugging, to display the value of a variable before the next part of a rule.

Set GPS

Select longitude and latitude fields. The arguments are precision and age. Precision represents a condition for how precise the GPS search needs to be used in the rule. It is set in meters. Age represents a condition for how old the GPS search result can be. It is set in seconds.

Variable, Shared

Define or modify a variable. You can use the variable later in the same script. Shared variables can be used even in other scripts within the same user interface component.

Scan Image

Allows you to initiate barcode scanning or image recognition from rules.

If, Else

Use to define conditions when a particular step should be performed.

Condition, Group And, Group Or, Ungroup

Use Condition to add another condition to the same If. Define if the all conditions must be met (AND) or only some (OR). Use Ungroup in nested conditions.

Export XML, Import XML

Rules can be exported and reused in a different location in the project or in a different project.

Edit XML

Display rule code in XML format.

Building a function step

Each rule consists of steps. Every type of step can be described as an expression with usually three parts (from left to right):

• Variable - usually this is the thing that we're about to modify in this step

• Operation - this is the operation, comparison or function that we perform

• Argument(s) (optional) - parameters of the function

Click Step on the toolbar to add an empty step to your rule.

Variables and arguments are using the dot notation.

Form variables

Click Pick Value and select the variable that you want to modify in this step from a drop-down list. Some of the available variables are listed below, the exact list depends on the rule.

Entity

Use if you want change the value of an entity field in the database.

Form

Use if you want to change how your form is displayed.

Tabs

Use to change a particular tab on your form.

Shared

Modify your shared variable. You have to declare a variable before you can modify it.

Caption

Modify the caption of your form.

IsFormEditable

Can the form be edited?

ChangedItem

This is often used in conditions to determine which item was changed. In Cell Click and Button Click rules, this is the name of the clicked item. In On Change events, it is a variable that can be assigned the changed entity field.

CommandsVisibleForNew

Should the commands be visible when creating a new record?

FormName

Used mostly in Select Form rules to control which form should be used to display a particular record.

Commands

ErrorMessage

A string variable where you can set an error message for form. In case of On Save event, this stops the saving.

WarningMessage

A string variable where you can set an error message for form. In case of On Save event, this does not prevent saving, user can decide to continue.

Form tab variables

These are the variables that you can work with on a form tab:

• IsVisible: Display or hide the tab

• IsSelected: Tab gains focus

• IsMaximized: Maximize the tab over whole form (no other field or list are visible, but the elements on left are visible, e.g., list view)

• IsExpanded: Is the tab is collapsed or expanded (in the app, tabs can be collapsed or expanded using arrow(“V”) button)

• IsLoaded: Ensure that the tab is loaded

• IsDirty: Has the tab been modified?

• IsEnabled: Can app users modify the tab content? (available for form tabs created using the Add Detail button)

• AllowCreateNew: For associated or unassociated lists, allow creating new items

Additional variables for media tabs

• IsEmpty: Does not contain data

• Caption: Caption of the tab (displayed in the app)

• CommandsMask: Enable or disable document actions; see JSBridge wiki for information about inputs

• IsEditable: Is the attachment tab editable for document edit actions?

• MaxImageWidth: The image is reduced to the specified maximum width

• MaxImageHeight: The image is reduced to the specified maximum height

• DesiredRatio: Specify the desired width to height ratio, for example, "1.3"

• EnforcementMode: Select whether and how to enforce the image limits (no enforcement, autocrop, autoresize, autocrop and resize, open image editor)

Form field variables

Some of the variables for form fields are universal:

• IsEnabled - Gets or sets whether the item is editable.

• IsVisible - Gets or sets whether the item is visible.

• Validate - Gets or sets whether the item needs validation. When set to true, the item cannot be empty; users have to enter or select a value.

• Focus - Set focus to the item.

• ErrorMessage - Gets or sets the item error message displayed during validation.

• Label - Gets or sets the item label.

• Style - Gets or sets the item's style.

Other depend on the field type:

Row Script variables

TemplateIndex

Used to assign different row designs to various rows

Row

Used to modify the text style of a particular field

Cell Click, Button Click variables

Handled

If false (default) the standard behavior is executed after the rule. If True, it is skipped.

DirectEdit

Controls how the changes to the entity are handled (if there are any).

• True and the entity is dirty after the rule executes, the entity is saved to storage (OnSave rule is run).

• False, if a property is changed the ChangeRule is run and the entity is added to the list of dirty entities to be saved on user command.

• Null (not-set, default), changes are ignored.

Scheduler variables

Source Entity

This is the entity from which tasks are created.

Activity Entity

This is the entity for tasks.

Questionnaire variables

Questionnaire

Handles every action referencing questionnaire record, handles the properties of the Questionnaire, e.g. clearing and changing ownerid (ID of the user creating the questionnaire in app)

Group

Handles every action referencing question group record, handles the properties of the question group element.

Questions

Handles actions related to questions of a particular group.

RootQuestions

If you use question groups in your questionnaire and have some questions that are outside of any group, this is used to reference them in the rules.

QuestionGroups

If you use question groups in your questionnaire and have some questions that are in a different group, this is used to reference them in the rules.

Shared

Modify your shared variable. You have to declare a variable before you can modify it.

Caption

Modify the caption of your questionnaire.

Command

Used in On Can Execute and On Execute rules to specify a command, its parameters (if available), and whether the command is enabled (visible) or handled.

ChangedItem

Used most often as a condition to specify which item of the questionnaire has been changed.

IsLoaded

Used in very specific cases, when you need to handle the loading of groups/question reload based on some conditions

SourceGroup

Used specifically in On Repeat rule editor, to set conditions or parameters based on the question group used as a source for the creation of a new one

SourceQuestions

Used specifically in On Repeat rule editor, to set conditions or parameters based on the question located in the group used as a source for the creation of a new one

Operations

Each variable data type will have a different set of functions. See the table for details.

Text = String, Memo
Number = Integer, Float, Decimal, Number

Arguments

After selecting the variable and the operation, you usually have to select one or more arguments. Some operations don't have arguments, for example "Clear". Some operations have multiple arguments, for example "Concat".

An argument can be either a constant value or a variable.

• Click the xy button to switch to variable.

• Click the π (pi) button to switch to a constant.

Building a condition

Conditions allow you to specify when (under which conditions) a set of steps will be executed. A condition is a part of a rule, where you test a variable against a value and act in one way if the condition is met by the variable or another way if not. Conditions always evaluate to true or false. You can chain conditions using AND and OR logical operators.

Similar to function steps, conditions also often have three parts: variable, operator, and argument(s).

Variables

The variables in conditions mostly overlap with variables in function steps. Some additional variables exist:

Configuration

Use to evaluate conditions related to a user, app, and device: businessunit, customerid, customeruserid, defaultcurrency, domain, isonline, language, organizationid, password, platform, projectversion, roles, systemuserid, url, username.

Configuration.roles allow you to modify the behavior of the app depending on the user role. For example, you can make a form read-only for certain security roles or enable a specific command only for a certain role. Use the Contains operator with roles, and specify either the name or the ID of the security role.

IsLoaded

IsLoaded property checks whether the form or questionnaire is fully loaded and visible on the screen, with all the values assigned. For example, you can use it to differentiate between the initial loading of a form and manual user change.

Relationship

Relationship allows you to determine from where a particular form/view/questionnaire opens. However, a relationship has to exist between the two records. Depending on whether the lookup relationship is on the original record or the destination record, either source or target is populated.

For example:

• If you display an account and go to its primary contact through a lookup on the account form, on the contact form, the relationship.source will be populated with the account reference (account.primarycontactid).

• If you display an account and go to one of its related contacts, on the contact form, the relationship.target will be contact.accountid.

• If you open a record directly from the home screen or from an unrelated list, no relationship will be defined.

In the case of questionnaires:

• The relationship target gets the object from where you entered the questionnaire in the user interface. For example, if you open a questionnaire from an Account form, the relation target is then the Account record. We call such a record the "regarding" record.

• The relationship source is the record from the form that you opened from the questionnaire. However, opening forms of other records from a questionnaire is very rare.

The relationship sourceUIElement is the tab name of the associated view from which you open a related record.

Operations

The operators in conditions are quite different from operators in functions.

Using variables

Rules support two types of user-defined variables:

• Variable: You can use the variable later in the same script.

• Shared: You can use a shared variable even in other scripts within the same user interface component.

Use the buttons Variable and Shared to declare a variable and assign an initial value to it.

1. Select a type: String, Boolean, Integer, Float, Decimal, Date Time, Lookup, Entity, Picklist, StringList.

2. Name the variable, for example MyString1.
   Don't use names identical to entity field names. Since release 19.0, Woodford will prevent you from using such names.

3. Assign an initial value to the value.

Once the variable has been initialized, you can use it in other steps and conditions.

If you stumble into an "Entity Not Loaded" error when executing rules, use the ContainsData operator to check if a variable has been populated before proceeding with your rule's logic.

Deleting variables

When you delete the variable, all steps that are using the variable on the left side will be also deleted.

Steps using the variable on the right side will reset and you have to define them again.

StringList type

StringList is a special type of variable that you can define. It represents an array or list of string variables. It has only a limited set of operations available.

To populate a StringList variable, you can either assign it a different string list or add strings using the AddItem step.

To work with the content of the array, use the Element At operation and specify the index of the string in the array.

Entity type

Variables of the type Entity are used to store a single entity record (with all its fields). There are multiple ways how to fill in the initial values of this variable:

• NewInstance: Create a new blank record of the selected entity.

• LoadReference: Load a related record from related entity.

• LoadFetch: Load a particular record from the database. Opens a new Filter editor window that allows you define a FetchXML command that finds the record.

After LoadReference or LoadFetch, use the ContainsData operator to check if a variable has been populated before proceeding with your rule's logic.

Shared variable limits

There's a limit to how many shared variables you can use.

• On forms and questionnaires, you can use up to 1000 shared variables.

• On views, you can use up to 750 shared variables.

The app displays an error if you go past this limit.

In the example above, a single shared variable in the On Change rule on the Contact entity form results in multiple entries in the Fields & Components pane (one for each field).

Global constants

In addition to the variables defined in rules, Woodford admins can define global constants. These are read-only and available in selected rules and JavaScript.

Option set filtering

You can use rules to filter the values available in an option set on a form. It also applies to Salesforce picklists.

Asynchronous operations in rules

The rules include multiple asynchronous operations:

• LoadFetch

• LoadReference

• LoadAggregate

• SetGps

Additionally, when we use the Assign operation to add a lookup to an entity, this behaves like LoadReference.

Asynchronous operations cannot be used in the following rules:

• On Can Execute

• Row Script

• Calendar rules

Code editor

Rules offer a no-code/low-code way of defining business logic. Some users don't mind code; in fact, they prefer it. For this reason, the rules editor also provides an alternate representation of the rules.

See also

• Execute JavaScript from rules

• How to make fields required  Blog

• More blogs with rules

Last updated: August 22, 2026