Access. Business Rules is available to three roles. SuperAdmin can create and edit rules. ProcureToPay Manager and ProcureToPay Agent have read-only access. See the Roles and Access Reference.
Overview
Two different mechanisms protect a rule set, and they behave differently.
Validation runs as you build. Where a rule contradicts itself or another rule, a banner appears and Save becomes unavailable, so the rule cannot be submitted until you resolve the conflict.
Field availability warnings appear afterwards, when a field a saved rule depends on is switched off elsewhere in your configuration. The rule is not rejected. It stays exactly as it was and stops applying to that field.
The distinction matters because only the first announces itself at the moment you can act on it.
What a blocked save looks like
Building a rule whose IF clause and THEN clause both target the same field produces an amber banner directly above the buttons:
Figure 1. The condition-action conflict, caught before saving.
The banner reads:
Fields for IF and THEN conditions cannot be the same.
Save becomes unavailable at the same time, so the rule cannot be submitted. Changing either field to a different one clears the banner and restores Save immediately.
A duplicate rule
Building a rule whose conditions and actions repeat those of an existing enabled rule produces a red banner and makes Save unavailable in the same way:
Figure 2. A duplicate rule, caught before saving.
The banner reads:
A rule with the same conditions and actions already exists. Please modify your rule or discard it.
and names the rule it clashes with, as Conflicting rule: <name>. That name is the quickest way to resolve it, because it tells you which existing rule to narrow, combine with, or disable.
The two banners carry different messages, and the condition-action conflict is amber while the duplicate is red. Both make Save unavailable.
Telling a blocked save from an incomplete one
Save is also unavailable whenever the rule is unfinished, for example a missing Rule Name or a condition row with no field chosen yet. No banner appears in that state, which is what separates the two cases. A banner means a rule that conflicts. An unavailable Save with no banner means a rule that is not yet complete.
Rows must be finished before another can be added
+ Add condition and + Add action are unavailable while the current row is incomplete, and become available once it has a field, an operator, and a value. A dimmed control here means an unfinished row above it rather than a limit on how many rows a rule may have.
Validation checks
Each check catches one way a rule can contradict itself or another rule; some are enforced in the picker, so the mistake cannot be built at all.
Table 1. Checks run before a rule is saved
| Check | What it catches |
|---|---|
| Duplicate conditions | A field is used in more than one condition in the same rule. Enforced by making the field unavailable in the picker, so the duplicate cannot be built. |
| Condition-action conflict | A field is used in both the IF clause and the THEN clause of the same rule. |
| Duplicate actions | The same target field appears in more than one THEN action. Enforced by making the field unavailable in the picker. |
| Duplicate rules | An enabled rule already uses the same conditions and targets the same fields in its actions. Caught before saving, and the clashing rule is named. |
A rule that fails one of the active checks cannot be saved until the conflict is resolved.
Save stays unavailable until the rule is structurally complete, so an unavailable Save with no banner means an incomplete rule rather than a failed validation check. The checks in the table run on rules that are complete enough to submit.
How each check reaches you
The checks do not all behave the same way. Two of them stop you before you can build the problem; the others report after the fact.
Duplicate conditions are prevented, not warned about. Once a field is used in one condition, that field becomes unavailable in the field list for every other condition row in the same rule, so the duplicate cannot be built. The block is on the field alone rather than on the field, operator, and value together, so a rule cannot test the same field twice even with different operators.
The same applies to actions. A field already set by one THEN action becomes unavailable in the picker for any other action row in the same rule, so a second action cannot target it.
The condition-action conflict is reported. It shows the banner described above and makes Save unavailable.
Exceptions to the condition-action conflict check
The condition-action check has two exceptions:
- It does not apply when the operator in the IF clause is Is Blank. Testing that a field is empty and then filling it is a coherent thing to want, so it is allowed.
- Entity may appear in both clauses when the operator is In.
How the Is Blank exception behaves
A rule whose IF clause tests a field with Is Blank and whose THEN clause sets that same field produces no banner, and Save stays available. The same pair of fields with Equals in the IF clause is blocked, so the check turns on the operator rather than on the field appearing twice.
This is what makes “fill it in only if it is empty” possible as a single rule.
What the duplicate check does and does not catch
The check compares the rule you are building against the rules already in the list, looking at the conditions and at the fields the actions target. The value an action sets is not part of the comparison, so changing only that value, setting Total Amount to a different number for example, still counts as a duplicate.
Changing the conditions is what clears it. Adding a second condition removes the banner and restores Save, even though the narrower rule can still apply to the same invoice as the original and still targets the same field.
That is the limit of the check. Two rules that both apply to one invoice and both set the same field are allowed, and which value survives is decided by Order Of Execution rather than by validation. Nothing on the page warns about that, so it is worth reading the execution order whenever two rules touch the same field.
To clear the banner, do one of the following:
- Change the conditions, by adding a condition or altering an existing one.
- Target a different field in the THEN clause.
- Edit the existing rule instead of adding a second one, if what you want is a change to how it behaves.
Field availability warnings
A rule can reference a field that is later marked not required, or switched off, in your field configuration. When that happens the rule is not deleted or edited, and its stored settings are untouched. The field’s display name is kept as it was when the rule was created, so the rule stays readable.
The rule list marks the affected rule in two ways. The whole row is highlighted amber, and a warning icon appears beside the target field that is no longer active. The row highlight tells you a rule is affected; the icon tells you which part of it, rather than only that something is wrong.
A legend under the table restates both cues, so the marking is explained on the page itself.
Figure 3. A rule referencing an inactive field. The row is amber and the target field carries a warning icon.
Hovering the icon shows:
This rule references one or more fields that are no longer active as per the configurations. The rule will not apply to inactive fields. Re-enable the field(s) or update the rule
The warning describes the rule, not any single document. What the rule actually does when an invoice arrives depends on how many of its target fields are still active.
Table 2. What a warned rule does at run time
| Situation | Behavior |
|---|---|
| Every target field the rule references is inactive | The rule does not run. |
| Some target fields are active and some inactive | The rule runs for the active fields and skips the inactive ones. |
| The referenced field is switched back on | The warning clears on its own. No edit to the rule is needed. |
A rule in the second state is the one to watch. It still runs, still reports no error, and silently does less than it used to. Nothing announces the change beyond the amber row and the icon in the list.
Clear a warning in one of two ways: re-enable the field, or edit the rule so it no longer references that field.
Fields are enabled and disabled where the agent is configured, not on the Business Rules page. Open Agent Co-workers, edit the agent, go to Define capabilities, then Field extraction. Each field there carries an Enable check box, and clearing one is what puts a rule that targets it into the warned state.
Because a field configuration change can affect rules written months earlier, it is worth reviewing the rule list after any change to field extraction settings. The warning is visible only to someone who looks at the list.
Results
You can tell a blocked save from an incomplete rule, name the check that stopped you, and recognize what validation leaves to you: two rules that both apply to the same invoice and set the same field, whose outcome is decided by Order Of Execution.
Related information
- To resolve a rejected save while building, or to take a conflicting rule out of service, see Create and Manage Business Rules.
- For the operators the conflict exceptions refer to, see Business Rule Conditions and Operators.
- For the actions these checks examine, see Business Rule Actions.