> **Source:** https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/overview
> **Site:** Leegality Knowledge Base — https://knowledge.leegality.com
> **About:** Leegality is a document execution platform covering eSigning, stamps, NeSL, workflows, and REST API integration.
> **Navigation:** Every article on this site has a plain-text version at `<article-url>.txt` (this format). To get an index of all articles with their `.txt` links, read: https://knowledge.leegality.com/llms.txt
> **AI Guide:** For instructions on how to navigate this knowledge base as an AI agent, read: https://knowledge.leegality.com/ai-readable.txt

---
# Rule Engine

You have been using rules all along without seeing them. Every v4 workflow runs on a set of built-in integrity rules — over a hundred of them — that keep configurations consistent behind the scenes. When selecting one eSign type automatically switches the incompatible ones off, that's a rule firing. The IRN format check that blocks a Proceed when a reference number is malformed — also a rule.

The Rule Engine opens this same machinery to you, so you can add logic specific to *your* process.

## The IF → THEN model

Every rule follows the same shape: **IF** a field's value meets a condition, **THEN** apply an action to another field.

```mermaid
graph LR
    A["Subject Field: Loan Amount"] --> B{"Condition: greater than ₹10,00,000?"}
    B -->|Yes| C["Action: set Mandatory = true"]
    C --> D["Target Field: Reviewer's Name"]
    B -->|No| E[No change]
```

The **IF** side checks the **Subject Field** against the **Condition**. The **THEN** side applies the **Action** to the **Target Field**. If the condition is not met, the field is left unchanged.

Read as a sentence: *IF Loan Amount is greater than ₹10,00,000, THEN the Reviewer's Name becomes Mandatory.*

Once you see this structure, every requirement becomes a fill-in-the-blanks exercise. These are the pieces you fill in:

| Component | What it defines |
| --- | --- |
| **Subject Field** | The field whose value the rule watches |
| **Condition** | The check applied to the subject field — *greater than ₹10,00,000*, *is filled*, *equals NRI* |
| **Target Field** | The field the rule acts on |
| **Action** | The change applied to the target field — set Mandatory, set Visibility, set a Value |
| **Outcome** | The resulting behaviour when the condition is met |
| **Trigger Method** | *When* the rule is evaluated — a field being clicked, changed, or blurred, or the user clicking Proceed on a specific stage. See the [full list of trigger methods](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule#step-4--choose-the-trigger-method) |

A rule can have more than one Subject Field and more than one Target Field.

## How a rule is expressed

In the editor, a rule's logic is written in Leegality's **rule language** inside the rule's **Create Rule** step — the same IF → THEN, expressed precisely enough for the engine to run. You don't need to learn the language to work with rules. The six components above are what you *capture*, as a [six-line spec](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/turn-a-requirement-into-a-rule); the language encodes them. From a good spec there are three ways to a working rule: configure one with ready-made logic ([Build your first rule](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/build-your-first-rule) provides it), learn to write the language (Advanced: LEEQL), or send the spec to Support and get the rule built for you.

## The four properties a rule can change

Every rule changes exactly one of four field properties. This gives you four rule categories:

| Category | Property | Example |
| --- | --- | --- |
| **Mandatory** | Turn a field's required flag on or off | Make Reviewer mandatory IF Loan Amount > ₹10,00,000 |
| **Visibility** | Show or hide a field (or an entire page) | Hide Co-applicant Name IF Loan Type = Personal |
| **Editable** | Lock or unlock a field | Lock Branch Code IF Source = LOS API |
| **Value** | Compute or assign a value | Stamp Duty Amount = Loan Amount × Stamp Duty % |

The **Value** category is the most powerful: the assigned value can be a constant, arithmetic across fields, a lookup, or a value copied from another part of the workflow. See [Rule categories](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/rule-categories) for the full taxonomy with examples of each.

## What a rule is not

The Rule Engine acts only on what happens **inside a single workflow**, triggered by **field values**, changing **field properties**. Time-based actions ("send a reminder after 3 days"), signer-triggered behaviour, template swaps, and anything spanning two workflows cannot be built as rules — they have their own solutions.

Before building (or promising) a rule, run the requirement through the three-question test in [What counts as a rule?](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/what-is-a-rule)

## Custom fields: your rule inputs

Most rules watch a **custom field** — a Loan Amount, a Customer Type, a Source flag — that you add to the workflow yourself. If the field your rule needs doesn't exist yet, create it first: see [Custom Fields](https://knowledge.leegality.com/document-execution/workflows/v4/custom-fields/overview).

> **Tip — Leegality can build rules for you**
>
> The Rule Engine is an advanced feature. If you know *what* you need but not how to set it up, write it down as a [rule spec](https://knowledge.leegality.com/document-execution/workflows/v4/rule-engine/turn-a-requirement-into-a-rule) and send it to our Support team at [support@leegality.com](mailto:support@leegality.com) — we'll configure it for you.