Rules

Rules are statements configured to automatically execute a procedure triggered by a certain condition. Basically, rules consist of two parts: criteria and actions. Criteria are conditions that must be met in order to trigger an action (e.g., a criterion can be that the numeric value of a field is within a specified range). Actions are operations to be performed on a target element (e.g., changing the value stored in a field). In other words, it’s an "If-Then" (if this happens, then do that) statement.

There are three different types of rules:

  1. Rules. Configured in the Rules manager. If their criteria are fulfilled, affect the data of the record(s) currently displayed, after saving the form (or affecting many records via imports). For example, a rule that sets today’s date value to a field, after ticking a checkbox and saving the form. See other examples here.

  2. Validations. Configured in the Rule editor, if their criteria are fulfilled, affect the behavior of the fields currently displayed, without having to save the form for the actions to take place. For instance, make a field mandatory based on another field. Read other examples here.

  3. Styles. Also configured in the Rule editor, if their criteria are fulfilled, affect the color of the fields currently displayed, without having to save the form for the actions to take place. For instance, set a color to a field box after typing a specific value. Take a look at other examples here.

Timeout on rule chain: In order to ensure a good performance of the application, there is a time limit for create and update transactions that are started from forms, up to 15 minutes, to be completed. If that time is exceeded without full action completion, the rule is interrupted, and the transaction is rollbacked. The user will get a notification if this occurs.

How rule triggers work

When a user updates a record and hits Save, our platform checks rules one by one to see if they should run. This works well, but there’s an important behavior to be aware of—especially when multiple rules depend on the same field.

What Happens When You Save a Record

  1. User input is collected - The values entered in the form are captured.

  2. Values are saved - These values are written to the database and also kept in memory as a snapshot of “what the user sent.”

  3. Relevant rules are selected and evaluated in order:

    • One by one, each rule is checked: first the trigger, then (if it passes) the actions are run immediately.

    • After a rule runs, the system moves on to the next rule.

How Trigger Conditions Read Field Values

When a rule’s trigger condition checks a field:

  • It first looks at the values the user just submitted.

  • If a field wasn’t included in the user’s input, it falls back to the current value in the database.

  • That database value can include changes made by earlier rules.

Why This Can Be Surprising

This means it’s possible for two rules to both run, even if they seem mutually exclusive.

Let’s say you have a field called Status on a record.

Rules

  • Rule 1:

    • Trigger: If Status is empty

    • Action: Set Status to Pending

  • Rule 2:

    • Trigger: If Status = Pending

    • Action: Send a notification

The user fills in a form, changing only the Name field. They click Save.

This is what happens step-by-step in the rule engine:

Step Description

1

The system saves the user’s submitted fields (only Name)

2

The Status field was not submitted, so it’s not in memory

3

The system starts evaluating rules one by one

4

Rule 1 trigger: checks Status → user didn’t submit it → falls back to database → it’s empty → trigger passes

5

Rule 1 action: sets Status to Pending in the database

6

Rule 2 trigger: checks Status → not submitted → falls back to database → now it sees Pending → trigger passes

7

Rule 2 action: sends the notification