Business rules

A rule is a decision the business makes every time a record is written: what this lead is worth, who picks it up, whether this discount is allowed, how urgent this case is. In EML a rule is a flowchart — a picture a sales manager can read and an engine can evaluate.

Anatomy of a rule section

Two directives above a flowchart turn it into a rule: %%meta kind: rules says how to read the diagram, and %%rule binds it to an entity and a lifecycle event.

%%meta kind: rules
%%rule leadScoring on Lead event: beforeCreate priority: 10
flowchart TD
    ...

Shapes carry the meaning

The node shape is not decoration. It is how the flowchart compiles into a GoRules decision graph.

A complete rule

Lead scoring: firmographics, then source, then revenue, then a grade. Each branch adds points; the circle is where they are totalled; the last diamond turns the total into a rating that routing and conversion both read.

%%meta name: Lead Scoring
%%meta kind: rules
%%rule leadScoring on Lead event: beforeCreate priority: 10
flowchart TD
    A([Start: Lead Captured]) --> B{employee_count >= 1000?}
    B -->|Yes| C[Add 35 firmographic points]
    B -->|No| D{employee_count >= 100?}
    D -->|Yes| E[Add 20 firmographic points]
    D -->|No| F[Add 5 firmographic points]
    C --> G{lead_source == referral?}
    E --> G
    F --> G
    G -->|Yes| H[Add 30 source points]
    G -->|No| I{lead_source == event?}
    I -->|Yes| J[Add 20 source points]
    I -->|No| K[Add 8 source points]
    H --> L{annual_revenue > 10000000?}
    J --> L
    K --> L
    L -->|Yes| M[Add 25 revenue points]
    L -->|No| N[Add 5 revenue points]
    M --> O((Compute lead score))
    N --> O
    O --> P{score >= 70?}
    P -->|Yes| Q[Set rating hot]
    P -->|No| R{score >= 40?}
    R -->|Yes| S[Set rating warm]
    R -->|No| T[Set rating cold]
    Q --> Z([End: Lead Scored])
    S --> Z
    T --> Z

Actions: when deciding is not enough

A decision flow works out an answer. An action is what the engine does with it. Without actions a modelled rule could only ever think; these are how it reaches the record and the rest of the application.

%%rule quoteDiscountApproval on Quote event: beforeUpdate priority: 10
flowchart TD
    A([Start: Quote Priced]) --> B{discount_percent > 40?}
    B -->|Yes| C[Reject: Above the maximum discount]
    B -->|No| D{discount_percent > 25?}
    D -->|Yes| E[Require VP approval]
    D -->|No| F{discount_percent > 15?}
    F -->|Yes| G[Require sales manager approval]
    F -->|No| H{discount_percent > 0?}
    H -->|Yes| I[Auto approve within rep authority]
    H -->|No| J[No discount applied]
    ...

    %%action escalateDiscount trigger-workflow when: discount_percent > 15 workflow: QuoteApprovalEscalation message: Discount above rep authority — holding the quote for approval
    %%action refuseDiscount validation-error when: discount_percent > 40 message: Discounts above 40 percent cannot be approved by anyone — reprice the quote

The when: expression is evaluated against the record being written. when: true fires on every write and is a legitimate choice — say it deliberately, because a missing when means the same thing by accident and the checker warns about it (EML282).

The eight rules in the CRM

Where they land in the application

Open one and you get the decision table the flowchart compiled into, with a test panel and a coverage check. This is a real editor: an operations person can change a threshold here without a deploy, and the model stays the source of truth for what gets seeded on the next generation.

Rules an administrator can write without you

The 25 seeded rule tables are not the ceiling. The same screen carries an automation builder, and it ships with its own documentation — written for the person configuring the system, not for the person who generated it.

When rules run

Rules are evaluated inside the transaction that saves the record. If one fails, the write is rolled back and nothing it changed survives. That is the difference between a rule and a reminder: you cannot get a record into the database that violates one.

The generated application shows this as a document status. Every save starts as Draft; the rules and workflows attached to the entity run together; if all of them succeed the record becomes Final. If any fails, the record stays Draft with the reason written onto it, so you can fix the cause and retry.