Writing efficient Jedox rules, order, markers, and the traps
· Jedox
A few habits separate rules that fly from rules that crawl. These are the ones that matter most as a model grows.
Once you are comfortable writing Jedox rules, the next skill is writing them so they stay fast as the model grows. Rules are evaluated on every read, so small habits compound into big differences. These are the ones I rely on.
Order is logic, not decoration
Jedox evaluates rules in order, and for a given cell the first rule whose area matches wins. That means specific rules must sit above general ones. If a broad rule is higher in the list, it will catch cells you meant a more specific rule to handle. I treat rule order as part of the logic: most specific at the top, fall-throughs at the bottom.
STET and CONTINUE
Two small tools earn their keep. STET keeps a cell's existing loaded value instead of overwriting it with the rule, which is how you let real data win over a calculation in selected areas. CONTINUE passes evaluation to the next matching rule rather than stopping at the first. Used deliberately, they let rules and loaded data live together cleanly.
# illustrative: a margin rule scoped tightly to one target element
['Margin %'] = ['Gross Margin'] / ['Revenue'];
Keep the target area on the left as narrow as the logic allows.
Markers for performance
Markers tell the calculation engine the dependency path of a rule: which source cells, when they change, should ripple through to the rule's target. Marking the right rules lets the engine recalculate only what actually changed instead of re-evaluating broadly, and it is what makes write-back and supervision behave well. On a large model, sensible markers are one of the biggest performance levers you have.
Avoid the broad-area rule
A rule whose area is wider than it needs to be does work on cells that never needed the calculation. Scope every rule to the smallest target that is correct. "It works" and "it works at 200,000 elements" are two different statements.
Beware rule chains
A rule that reads a cell produced by another rule, which reads yet another rule, forces the engine to walk the whole chain on every read. A little chaining is fine; deep chains are a silent tax on every report. When I am handed a slow cube, tangled rule dependencies are one of the first things I check.
Test at real volume
A rule is fast on a demo dataset and slow in production because the only thing that changed is the number of cells it touches. Test rules against realistic data volumes, open the actual reports your users will open, and watch where the time goes before you call it done.
The habits, distilled
Specific rules first, STET and CONTINUE used on purpose, tight areas, markers where they help, shallow dependency chains, and tested at real scale. Rules are the most powerful thing in Jedox and the easiest place to wreck performance without noticing it. These habits keep them on the right side of that line.