Decisions and business rules

A decision in BPA separates business rules from process flow. Instead of nesting conditions in the process, the process asks a decision a question, here "does this credit request need finance approval, and who approves it?", and branches on the answer. The rules sit in tables the business can read, so Dan can review and change the credit routing without reading a process diagram.

Decision tables and text rules

A decision has input and output parameters, typed with data types, and one or more rules. SAP's tutorial describes two rule types: a decision table, a tabular rule with condition columns and result columns, and a text rule, a set of if-then expressions. For routing questions with several inputs, decision tables are easier to review, because every combination is a visible row.

Look at the table the way a tester does. Are the ranges complete, with no gaps and no overlaps? What happens at exactly 25,000 and exactly 100,000? Is "50 vehicles or more" inclusive? A decision table is a specification you can test row by row, but only if the boundaries are explicit. Check how your decision handles multiple matching rows (the hit policy, where your tenant offers one) and what it returns when no row matches.

Building the decision, step by step

1. In the project, create a decision named Credit Routing.
2. Create the data types CreditRequest (fleet size, requested limit, currency) and CreditRouting (finance approval yes/no, approver group).
3. Add an input parameter of type CreditRequest and an output parameter of type CreditRouting.
4. Add a rule of type decision table; add condition columns for fleet size and requested limit and result columns for the two outputs.
5. Enter the four rows. Write ranges with explicit operators (for example greater than 25000 and less than or equal to 100000).
6. Test the decision with sample inputs, using the decision editor's test function where your tenant provides it, before using it in the process.
7. In the process, add the decision step, map its input from the form fields, and use its outputs in the condition and as the recipient group of Dan's approval.

Boundary values: the test table

Decisions in the process context

The process passes inputs to the decision and receives outputs, which it then uses in a condition and as the recipient group for Dan's task. Two mapping errors are common. First, the decision input is bound to the wrong field, for example the fleet sales comment instead of the requested limit; the decision runs but evaluates nonsense. Second, the output group is not mapped to the approval recipients, so the task goes to a default group. Test the decision alone first, then test it inside the process with the same boundary inputs: if the standalone and in-process results differ, the mapping is wrong, not the rule.

Who owns the rules

Decisions make rules visible, and visible rules need an owner. Dan owns Credit Routing: he approves every change to thresholds and groups. Kenji's team owns the data types and the mapping into the process. A rule change is a change request like any other: changed in the DEV tenant, tested with the boundary table, released as a new project version and promoted. "We'll just edit it in production" is how decisions drift from policy.

What goes wrong in testing

• Gaps between ranges. A limit of exactly 25,000.50 falls between "up to 25,000" and "over 25,001": no row matches.
• Overlaps. Two rows match the same input, and the result depends on rule order or hit policy.
• No-match behavior untested. The decision returns an empty result and the process routes to "no approval".
• Currency assumed. A limit entered in MXN by the Monterrey team compared as USD. Contoso's form fixes the currency to USD for 1710.