Docupath evaluates transformation and rejection rules across several scopes (Trading Party Pair, Trading Party, Organization, Country, and Global). Scope determines the order in which matching rules run, from most specific to most general. It is important to understand that scope precedence is an execution order, not a filter that picks a single winning rule.
For transformations, every matching rule runs, and the value a document ends up with depends on the run order and on how each rule's conditions evaluate against the document as it is progressively transformed. For rejection rules, the first matching rule (most specific) rejects the document and evaluation stops. Understanding this behavior is essential to predicting the final outcome when more than one rule applies.
How It Works
The Scope Execution Order
Rules are evaluated from most specific to most general:
Order | Scope | Description |
1 (most specific, runs first) | Trading Party Pair (A+B) | Bilateral relationship between a specific supplier and customer |
2 | Trading Party (A or B) | Single trading party appearing as Primary or Secondary Party |
3 | Organization | The organization the document is assigned to |
4 | Country | Country-based conditions within Organization or Global scope (not a dedicated scope) |
5 (most general, runs last) | Global | Tenant-wide rules applying to all documents |
This order is fixed and deterministic. The same document processed against the same rule set always produces the same outcome. Precedence is determined by scope, never by rule creation date.
Disabled Rules Are Excluded Before Ordering
Only enabled rules take part in this evaluation at all. A rule that has been switched off is filtered out before the scope ordering is applied, so it never runs and never appears in the execution sequence. It is not treated as a rule that ran and did nothing; from the engine's point of view it is not there.
This matters more than it first appears, because a disabled rule changes the outcome of the rules that remain. Conditions are re-evaluated against the document as modified by whatever ran earlier, so removing a rule from the sequence can allow a later rule to match that would previously have been skipped. See "Resolving Conflicts Between Overlapping Rules" below for a worked example.
Rules are enabled by default, including every rule that existed before enable/disable was introduced, so evaluation is unchanged until a rule is explicitly switched off.
How Transformation Rules Are Applied
All matching rules run, not just the most specific one. Docupath does not stop at the first matching scope.
Disabled rules are skipped entirely and take no part in the sequence.
Rules run in scope order: Trading Party Pair, then Trading Party, then Organization, then Country, then Global.
Each rule's conditions are re-evaluated against the current state of the document, which already reflects any changes made by rules that ran earlier.
A
SETaction overwrites the target field. So when two rules write the same field and both conditions are still satisfied, the rule that runs later (the more general scope) overwrites the earlier one, and its value becomes the final value.Because conditions are re-checked against the transformed document, an earlier rule that changes a field can prevent a later rule from matching: if the later rule's condition depends on the field that was just changed, that condition may no longer be true, and the later rule is skipped.
How Rejection Rules Are Applied
Rejection rules are evaluated in the same scope order, most specific first.
Disabled rejection rules are skipped entirely, so a disabled rule cannot reject a document no matter what it matches.
The first enabled rule whose conditions match rejects the document with its reason, and evaluation stops immediately (no later rejection rules are checked).
Any single matching rejection rule is enough to reject the document. A more specific rule cannot cancel a rejection; it can only reject earlier, with its own reason.
Disabling the rule that used to reject first does not necessarily stop the document being rejected. The next enabled matching rule becomes first and rejects instead, with its reason, so the recorded rejection reason can change even though the outcome does not.
Resolving Conflicts Between Overlapping Rules
When more than one transformation rule targets the same field, the result follows the execution model above, which can be counter-intuitive. Whether the more specific or the more general rule wins depends on whether the later rule's condition is still true after earlier rules have run.
Case 1 - overwrite (the more general rule wins the value).
Trading Party rule: If Buyer Name = ABC, set Ship To = 123
Organization rule: If Buyer Name = ABC, set Ship To = 456
Both conditions match. The Trading Party rule runs first and sets Ship To = 123. The Organization rule runs next; its condition still matches (Buyer Name was not changed), so it overwrites Ship To = 456. Final value: 456.
Case 2 - condition invalidated (the more specific rule wins the value).
Trading Party rule: If UOM is empty, set UOM = Box
Organization rule: If UOM is empty, set UOM = Kilograms
The Trading Party rule runs first and sets UOM = Box. When the Organization rule runs, UOM is no longer empty, so its condition fails and the rule is skipped. Final value: Box.
The difference between the two cases is the condition. In Case 1 the shared condition (Buyer Name) is not touched by either action, so both rules fire and the later one wins. In Case 2 the earlier action changes the exact field the later rule tests, so the later rule no longer matches. This is a known characteristic of the current engine: for transformations the outcome is driven by execution order and condition re-evaluation, not by an explicit "most specific wins" rule.
Case 3 - disabling a rule changes what a different rule does.
Take the Case 2 pair and disable the Trading Party rule:
Trading Party rule (disabled): If UOM is empty, set UOM = Box
Organization rule: If UOM is empty, set UOM = Kilograms
In Case 2 the Trading Party rule ran first, filled UOM, and the Organization rule was skipped because its condition no longer held. With the Trading Party rule disabled, nothing fills UOM first, so the Organization rule's condition is still true when it runs and it now fires. Final value: Kilograms.
The Organization rule was not edited, yet its effective behavior changed. When you disable a rule, check the other rules that write or test the same fields, because a rule that was previously being suppressed can start firing.
Same-scope tie-break (CONTAINS specificity). When two transformation rules within the same scope both use a literal CONTAINS condition on the same field, the rule matching the longer value is applied last, so the more specific text wins. This ordering applies only within a single scope, not across scopes.
Verifying Which Rule Applied
To confirm what happened to a specific document:
Check Activity Logs: Navigate to Activity > Document Processing.
Expand the document record to view processing details.
Review before/after values: most activity log entries show the field values before and after.
When multiple rules touched the same field, the before/after trail shows the sequence of changes and the final value.
Check whether the rule is enabled. If a rule you expected to run left no trace at all, confirm its switch is on. On the Transformations and Rejections lists, expand the rule group and check the individual rule's switch: a group's row switch shows as on when only some of its rules are enabled, so the group looking active does not mean every rule in it is.
Supported Configurations and Options
Feature | Supported | Notes |
Trading Party Pair scope | Yes | Runs first; bilateral rules requiring an exact match of both parties |
Trading Party scope (A or B) | Yes | Single-party rules |
Organization scope | Yes | Matches the organization the document is assigned to |
Country-based conditions | Yes | Implemented as conditions within Organization or Global scope |
Global scope | Yes | Runs last; tenant-wide baseline |
Multiple rules per field | Yes | All matching transformation rules run; the last one to run whose condition still holds wins the value |
Enable/disable per rule | Yes | Disabled rules are excluded before ordering and never run |
Enable/disable per rule group | Yes | Cascades to every rule in the group |
Manual precedence override | No | The scope execution order is fixed |
Reordering rules within a scope | No | Order within a scope is not user-configurable; disabling a rule is the way to take it out of the sequence |
Mixing AND and OR in one rule | No | A single rule uses either all-AND or all-OR condition logic |
Other Technical Specifications
Parameter | Specification |
Scope execution order | Trading Party Pair (1) -> Trading Party (2) -> Organization (3) -> Country (4) -> Global (5) |
Disabled rule handling | Filtered out at processing time before scope ordering; never evaluated and never logged |
Default state | Enabled, including rules created before enable/disable existed |
Transformation application | All matching rules applied in scope order; |
Transformation condition re-evaluation | Each rule is evaluated against the document as modified by earlier rules; an earlier change can cause a later rule's condition to fail and be skipped |
Rejection application | Evaluated in scope order, most specific first; the first matching rule rejects and evaluation stops |
Same-scope CONTAINS tie-break | Within one scope, the longer literal |
Rule groups per scope | Maximum 100 per organization |
Rules per group | Maximum 500 |
Deterministic evaluation | Yes; the same document always produces the same outcome |
Audit trail | Activity logs record before/after field values |
Notes
Precedence is execution order, not a winner-take-all filter (transformations). A common misconception is that the most specific matching rule wins and lower scopes are ignored. For transformations this is not how the engine behaves: all matching rules run, and because
SEToverwrites, the more general rule (which runs later) can overwrite a more specific rule's value. Plan overlapping rules with this in mind.To have a specific rule reliably win over a general one on the same field, design the conditions so the general rule no longer matches after the specific rule has run (see Case 2), or avoid having both target the same field.
There is currently no in-product warning for conflicting transformation or rejection rules; their combined effect is only visible in the processed document and the activity log.
Known Limitations and Edge Cases
General-scope overwrite of specific-scope values. Because transformation rules run most-specific-first and
SEToverwrites, an Organization or Global rule can overwrite a Trading Party rule's value on the same field when both conditions still match. This is determined by execution order, not by an explicit specificity ranking.Rejection cannot be cancelled by a more specific rule. Any matching rejection rule at any scope rejects the document; a more specific rule can only change which reason is recorded (by matching first), not prevent rejection.
Trading Party Pair specificity. Bilateral rules require an exact match of both parties; a single-party ("A or B") rule does not trigger for a non-matching counterparty.
Disabling one rule can activate another's effect. Because conditions are re-evaluated against the document as modified by earlier rules, taking a rule out of the sequence can let a later rule match that was previously suppressed (Case 3). Disabling a rule is therefore not always a purely subtractive change, and its effect is not confined to the rule you switched off.
A partly-enabled group still looks active. A rule group's row switch is on when any rule inside it is enabled, so a group can appear active while the specific rule you care about is off. Expand the group and check the individual switch, or read the "X of Y rules currently enabled" indicator.
No warning for rules made redundant by disabling. Just as there is no in-product warning for conflicting rules, there is none for a rule whose behavior changes because a neighboring rule was disabled. The combined effect is visible only in the processed document and the activity log.