{
  "id": 10112063,
  "title": "The Expression Engine Is Small. That Is Exactly the Problem.",
  "url": "https://urgent.news/2026/09/27/the-expression-engine-is-small-that-is-exactly-the-problem",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-27T01:46:15.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/informat/the-expression-engine-is-small-that-is-exactly-the-problem-g14"
  },
  "original_language": "en",
  "account": "In June, a distributor customer reached out to us about a quote that should not have been generated. Their quoting app features a validation rule: the discount field cannot exceed thirty percent unless a specific approval flag is set. This rule was implemented by the customer's finance lead using the platform's formula editor during a product-line migration. Despite the rule, the quote in question had an eighty percent discount. The validation formula had never been triggered during the import of the quote into the database because imports are not treated as forms. This incident made me reconsider the smallness of a component I had previously considered insignificant: the expression engine. This engine is not a single feature but six different subsystems, each with its own parsing method. These six subsystems include default field values, validation rules, form section visibility conditions, workflow branch conditions, report and list view filters, and threshold checks in automations. The inconsistencies in how these expressions are parsed across the platform can lead to confusion and mistrust among users. The expression engine is a language that appears in six locations, providing six opportunities for disagreement. The day a user realizes that \"empty\" means something different in a validation rule versus a workflow branch is the day they lose trust in every formula they encounter. The discount incident also taught me that a formula is not just text; it is a dependency. When a finance lead creates a validation rule referencing a field called \"Approved,\" they are making a promise that the referenced field will exist and that the formula must re-evaluate when the field changes. Deleting or renaming a field can break these dependencies, leading to unexpected failures at runtime. The ideal solution would be a dependency graph that clearly shows all references and updates formulas automatically when changes occur. A platform where users fear to rename fields may inadvertently discourage them from evolving their applications over time. The expression engine's design also involves handling missing values. Every business table contains gaps, such as quotes without close dates, orders without discount fields, or contacts imported without phone numbers. The question arises: what happens when a formula encounters these missing values? Should an empty text field be treated as null or an empty string? Should an untouched number be considered null or zero? Crucially, does a validation rule that cannot produce an answer pass or fail? We decided that a rule unable to provide an answer should fail closed. A rule stating \"this must be under thirty percent\" cannot vouch for a number it cannot see. The type coercion issue is another concern. A formula language that silently converts \"10\" to 10 may be user-friendly for a while but becomes a liability in the long run due to non-numeric strings. We chose to be strict and provide explicit conversion functions, resulting in fewer bugs related to silent coercion. Date computations pose additional challenges. Our platform carries scar tissue from formulas that computed days overdue differently depending on the server, before we decided to treat zoned instants and plain calendar dates as different types. The expression engine's execution contract is equally important. Which expressions run in the browser during user interaction, and which run on the server during the write path? Visibility conditions need to run instantaneously, so they execute client-side. Validation, computed fields, and workflow branches, however, must run server-side, where every data point is checked against the same checkpoint. Forms, imports, API calls, and automations all require expressions to run server-side. The discount formula executed correctly because it ran in the right place. The deep design question extends beyond grammar to the execution contract: which expressions run where.",
  "summary": "In June, a distributor customer of ours called about a quote that should never have existed. Their quoting app has a validation rule: the discount field must stay under thirty percent unless the record carries an approval flag. The rule had been there for a year. It was written by their finance lead herself, in the platform's formula editor, in about four minutes. The quote in question had a…",
  "key_points": [
    "Expression engine comprises six subsystems with unique parsing methods",
    "Inconsistencies in parsing lead to user confusion and mistrust",
    "Validation rule failure when referenced field deleted or renamed"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}