Build1 publisher3 min readPublished Updated
Bulk import carried an 80% discount past a validation rule that only ran in the form
One low-code platform's builder says a bulk import saved a quote at 80% discount because the finance team's 30% cap ran only in the form. The builder's fixes, one parser for six subsystems and fail-closed nulls, treat the formula engine as shared infrastructure.
The Engineer · Build desk
What happened
- A distributor's finance lead wrote a validation rule capping quote discounts under 30% unless an approval flag was set, and it stood for a year.
- In June an 80% discount quote surfaced; a bulk import during a product-line migration had created it, and the rule evaluated zero times.
- The platform's expressions appear in six subsystems, and its early version parsed them six different ways before the vendor unified the parsers.
- Field deletes now list dependent formulas, renames update every formula atomically, and formula edits are checked against the schema at save time.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure Records that enter through an import sit outside a form-bound rule, so a cap that looks enforced in the editor guards only what staff key in by hand.
- decision Running rules on imports while nulls fail closed will reject legacy rows with empty fields, so migration tooling needs a rejection report before the switch.
- constraint Without save-time schema checks, a renamed field silently breaks formulas, and customers who get burned stop changing their apps.
A validation rule bound to a form is checked when that form saves. A bulk import writes rows through its own path, and nothing on that path calls the rule. The platform's builder put it in one line: "the rule only ran where the form ran, and an import is not a form." [4] The imported quote landed 50 percentage points over the cap [8]. A rule that never evaluates also never fails, so the first signal was the customer's phone call [1].
The author's case for treating the engine as infrastructure is that the same language runs in six places [5]. When each place has its own parser, the meaning of an expression drifts between them. The example given is "empty" meaning one thing in a validation rule and something subtly different in a workflow branch [6]. Merging the parsers was, in the author's words, "tedious work with no visible payoff" [7]. It was the right call. A single grammar and evaluator let a user who learned the language once predict the platform everywhere [7].
References are the second layer. The finance lead's rule pointed at a field called Approved, and a few thousand formulas like it form a dependency graph "that nobody drew and everybody relies on," the author wrote [9]. Storing formulas as text and resolving names only at evaluation time produces a twin of the import bug: a formula "invisible in the place people check and wrong in the place they don't" [11]. The platform moved the check to save time, and to the moment someone deletes or renames a field, when the person who can fix the formula is still in the editor [10]. The author ties this to whether customers dare to change their apps after six months of use [16].
Missing values took the most argument per line of spec, according to the author [15]. The open cases included whether an empty text field is null or an empty string, and whether an untouched number is null or zero [15]. The platform decided that a validation rule which evaluates to null fails closed, because a 30% rule "cannot vouch for a number it cannot see" [12]. Told of this a month after the incident, the finance lead said: "Obviously." [13] The author wrote: "It was not obvious." [13]
Fail-closed nulls and the import gap meet at the next migration. The author's own examples of holes in business tables include a contact imported without a phone number [14]. If imports start running the same rules as forms, legacy rows with an empty referenced field will fail on the way in. I think that is the right default for a pricing rule. It also means the import tool needs a per-row rejection report and a way to correct rows in bulk before the rules can be switched on for that path.
The post is one vendor's account of one incident on its own platform [17]. It does not state that bulk imports now evaluate validation rules, and it does not survey how other low-code platforms bind rules to write paths.
What to watch
- Whether the vendor states that bulk imports and other non-form writes now evaluate the same validation rules as forms.
- Whether other low-code platforms document which write paths, such as imports and automations, run validation rules.
- How the import tool reports and lets users correct rows that fail closed on missing values once rules apply there.