# 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**](rules_manager.md). If their criteria are fulfilled, affect _the data of the record(s) currently displayed, after saving the form_ (or affecting many records via [imports](imports.md)). 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](examples_of_rules.md).

2.  _Validations_. Configured in the [**Rule editor**](rules_editor.md), 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](examples_of_validations.md).

3.  _Styles_. Also configured in the [**Rule editor**](rules_editor.md), 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](examples_of_styles.md).

> **Note:**
> 
> _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 |