Access. Business Rules is available to three roles. SuperAdmin can create and change rules. ProcureToPay Manager and ProcureToPay Agent have read-only access. See the Roles and Access Reference.
Overview
Business rules are part of an AP Invoices Agent Co-worker. A business rule is conditional logic that runs while an invoice is being prepared. The rule looks at the document, and where the document matches what the rule is watching for, the rule fills fields in for you.
The point is to stop your team retyping the same coding decisions. If invoices from one supplier always belong to one department, that is a decision worth making once, as a rule, rather than on every invoice that arrives.
You can hold as many rules as you need. Each one can be turned on or off on its own, and you control the order they run in.
A rule is not the last word on a field. A value from a purchase order or contract, a configuration option, or predictive coding is applied ahead of a rule, which is the usual reason a correctly built rule appears to do nothing. See Where a rule sits against everything else.
Business rules apply to invoices. The product has no separate credit memo rule set and no record-type selector on the Business Rules page.
There are two different rule systems, and this is not the other one. Business rules are IF-THEN logic that sets field values on an AP Invoices document. The Rulebook holds plain-language rules for how an AP Helpdesk agent handles mail. They are configured in different places and do different work. See Rulebook.
How it works
Every rule is an IF-THEN-ELSE statement:
- IF. One or more conditions about the document. Every condition has to be true.
- THEN. The actions to perform when they are. A rule can set a field, copy a value from another field, calculate an amount, or clear a field.
- ELSE. Optional. A different set of actions for when the conditions are not true.
Some rules should apply to every document, with nothing to test. Select Apply to all documents and the IF clause is skipped; the THEN actions then run on every document. Supplier-level defaults are usually written this way.
What a rule is made of
Six parts make up every rule, and only Rule Name is required.
Table 1. The parts of a rule
| Part | What it does |
|---|---|
| Rule Name | The label in the rule list. Required. The only field marked with an asterisk. |
| Description | Optional note for whoever reads the rule next. |
| Order Of Execution | The rule’s position in the sequence. Lower numbers run earlier. |
| Conditions (IF) | What has to be true. Conditions combine with AND. OR is not available. |
| Actions (THEN) | What happens when the conditions are met. |
| Actions (ELSE) | Optional. What happens when they are not. |
The AND-only design matters when you plan a rule. To express “either of two things”, build two rules, or build one rule with an ELSE clause.
Where a rule sits against everything else
A rule is one of several things that can populate a field, and it does not outrank all of them. Values are applied in a fixed order of priority:
Table 2. Priority order for populating a field
| Priority | Source |
|---|---|
| 1 | Purchase order or contract details |
| 2 | Configuration Options |
| 3–5 | Predictive coding, by confidence tier |
| 6 | Business rule |
| 7 | Manual entry |
This order explains the most common question about business rules: why a rule that looks correctly built appears to do nothing.
A business rule fills a field only where nothing above it already has. Three sources outrank it: a value taken from a purchase order or contract, a configuration option, and predictive coding. Any of them populating the field first is enough to make a correctly built rule look as though it never fired.
Purchase order, contract and configuration values carry no confidence score, so nothing on the invoice signals that one of them overrode the rule. Predictive coding does show a confidence tier, which makes it the easiest of the three to spot. Check all three before you start rewriting the rule.
Only manual entry sits below the rule, which is what you want: a person correcting a field on screen is not undone by automation.
Who can do what
Business Rules is available to three roles. One of them can change rules; the other two can read them.
Table 3. Access by role
| Role | Access |
|---|---|
| SuperAdmin | Full. Create, edit, enable, disable, reorder, duplicate, delete, and export rules. |
| ProcureToPay Manager | Read-only. Can read every rule and export the set, but cannot create, edit, or delete. |
| ProcureToPay Agent | Read-only, the same as the Manager. |
The Manager has no rule-editing rights the Agent lacks. The two roles resolve to the same access. A rule changes how every future invoice is coded, so it sits with the role that owns agent configuration rather than with the people working the queue.
Other roles do not see the page at all. SmartVendor Settings does not appear in their navigation, and opening a link to a rule sends them to a different page rather than showing a message. Where a colleague cannot follow a link you sent, their role does not carry business rules access.
A read-only role can still export. Search, filtering, and the export control stay available, so either ProcureToPay role can take the whole rule set away as a CSV file. The export carries live configuration, including the values your rules match on.
If you hold more than one role
A user can be given several roles at once, and one of them is active at a time. Business rules respond to the active role rather than to the full set, so someone holding both SuperAdmin and ProcureToPay Manager sees a read-only page whenever ProcureToPay Manager is the active role.
Switch the active role from the profile menu at the top right of the screen. Where only one role is held, no switch is offered.
Where a role cannot change something, the control is not shown rather than dimmed, so a missing button is a role difference rather than a fault. On a read-only page the + Add Rule button is absent altogether.
The Business rules section of the Agent Co-worker wizard is read-only for everyone, including SuperAdmin. It carries a note pointing to SmartVendor Settings, where rules are edited.
Why it is designed this way
The AND-only conditions and the single fixed sequence are deliberate. A rules engine with OR, nesting and dynamic ordering can express more, but the result is a body of logic nobody can read six months later. Keeping each rule shallow and the order explicit means a rule can be understood on its own, and the sequence can be read off the list.
The same thinking shows up in the smaller choices. Date conditions are expressed only as ranges relative to another date, rather than as equalities. An invoice date rarely needs to equal an exact day, but often needs to fall inside a window. Conflicts within a single rule are caught before it can be saved rather than left to surface later. A disabled rule keeps its whole definition, so taking a rule out of service costs nothing and is reversible.
What this means in practice
- Rules act on extracted values, so settle field extraction first. A rule that tests a field the agent is not extracting has nothing to test.
- Order matters when rules feed each other. If one rule sets a field a later rule reads, the first has to carry the lower number. See Create and Manage Business Rules.
- Where you read a rule is not where you change it. Rules are created and edited in SmartVendor Settings.
- A rule can stop applying without failing. If a field a rule targets is later switched off in your configuration, the rule keeps its settings but stops acting on that field, and the list shows a warning. See Business Rule Validation and Field Warnings.
Before you build anything
A rule can only test and set the fields your agent is configured to extract, so settle field extraction before writing rules. Rules are created and edited in SmartVendor Settings; the copy of the list inside the Agent Co-worker wizard is read-only.
Each article in this section opens with Who this is for, describing what you are trying to do, and Access, saying which roles can change anything. The two are separate on purpose: a ProcureToPay Manager or Agent cannot change a rule but often needs to read one.
Results
You can say why an AP Invoices field holds the value it does, whether from extraction, a business rule, or a configuration option. You also know which of the three roles can change the rule that set it.
Related information
- For the operators each field type offers, see Business Rule Conditions and Operators.
- For worked use cases, see Business Rule Use Cases.