Transformation rules are evaluated serially, in the order they are configured. Each rule sees the values written by the rules that ran before it, rather than the document as it was first extracted. This means a set of rules behaves the way it reads on the page: a rule can act on a value an earlier rule produced, and a fallback rule can cancel itself once an earlier rule has already found an answer. Scope precedence is unaffected, so the most specific scope still decides the value that ships.
How It Works
Rules See Each Other's Work
Within a scope level, rules run top to bottom in configured order, and each rule reads the current state of the document, including any values written by earlier rules.
A typical article-code mapping is three rules:
Rule | Condition | Action |
1 | Article Name contains a code from your catalog | set Article ID to that code |
2 | Article ID is in no row of your catalog | set Article ID to |
3 | Description contains a code from your catalog | set Article ID to that code |
Read in order, that is: try the article name, then try the description, and only if neither has the code, record that it could not be found. Serial evaluation is what makes the set behave that way:
Rule 1 sets Article ID to W9125H Rule 2 re-reads Article ID, sees W9125H IS in the catalog, so it does not apply Rule 3 has nothing left to do
A "could not find it" rule cancels itself as soon as another rule has found a value. The result also no longer depends on which field a value happens to land in during extraction. Where a single printed column is split into an Article Name and a Description, a reference may appear in both fields or in only one; because each rule reads the current state, the outcome is the same either way.
One Rule Can Build on Another
Because a rule sees what earlier rules wrote, work can be split across rules deliberately. You can write one rule that derives a value and a second rule that acts on that derived value, and the second rule will see the first rule's answer.
Scope Precedence and Evaluation Order
Rules are evaluated weakest scope first, so the strongest scope writes last and its value is the one that ships:
Global -> Country -> Organization -> Trading Party specific (only Party A or only Party B) -> Trading Party specific (Party A + Party B)
This is the same precedence order documented for transformations generally. Evaluation order is arranged to produce it: because the strongest scope writes last, it wins any contested field.
Each Scope Level Reads the Original Document
A rule's condition often reads the same field that another rule writes. If a weaker rule overwrote a field that a stronger rule's condition depends on, the stronger rule would stop matching and never fire, and the weaker rule would silently take the field.
To prevent that, each scope level re-reads the document as it arrived, and sees only the writes made by rules at its own level. So the "rules see each other's work" behavior applies within a scope level, while conditions at each level are still evaluated against the original extracted values.
Rules With More Than One Action
A rule with several actions applies all of them. A rule that says set Article ID to blank and set UOM to blank clears both fields. Evaluation decides rules, not individual fields, so the halves of a single rule are never separated.
Two Rules Writing the Same Field
Where two rules at the same scope level could both convert the same field, the first one to apply wins. If one rule says UOM containing "szt" means EA and another says UOM containing "op" means BX, a printed OP. 1 SZT satisfies both conditions. The first rule applies and changes the value, so the second rule is reading a value that no longer matches its condition.
If you have a pair of rules that overlap this way, make their conditions distinct so the intended one is unambiguous.
Supported Configurations and Options
Configuration | Detail |
Evaluation model | Serial, in configured order, within each scope level |
Scope evaluation order | Weakest to strongest: Global, Country, Organization, Trading Party specific (only Party A or only Party B), Trading Party specific (Party A + Party B) |
Condition inputs | The document as it arrived, plus writes made by earlier rules at the same scope level |
Multiple actions per rule | All actions in a rule are applied |
Two rules writing the same field | The first rule to apply wins at that scope level; the strongest scope wins overall |
Configuration required | None. Serial evaluation applies to all accounts and needs no setup or integration change |
Other Technical Specifications
Behavior | Detail |
Change report entries | One entry per field, showing the value the field held before the transformation stage and the value that shipped |
Superseded rules | A rule whose value did not survive is listed under |
Report accuracy | A reported change always matches the value the document holds |
Rejection rules | Evaluated on the final, transformed values |
Matching behavior | Unaffected. How a rule compares text is configured separately, described in Matching Instructions for Transformation Rules |
Notes
Serial evaluation applies within a scope level. Conditions are still evaluated against the original extracted document at each level, so a weaker rule cannot disarm a stronger rule by overwriting a field the stronger rule's condition reads.
Because every action in a rule is applied, a rule that was previously relied upon to apply only part of itself will now apply in full. Review multi-action rules where only one action was the intended effect.
Where two rules convert the same field on overlapping conditions, the earlier rule takes it. The reliable fix is to narrow the conditions rather than to reorder the rules, since order alone does not make the intent clear to whoever maintains the rule set next.
Ordering actions within a single rule still matters. Actions execute top to bottom, so conversions that depend on each other should be sequenced deliberately.
Scope precedence is unchanged by serial evaluation. If a value is not the one you expected, check the scope of the competing rules before checking their order.