Groups & Hit Policies
In Rulebricks, conditions in a decision table can be grouped in various ways. Often, this grouping functionality provides an elegant solution to situations where your decision tables would otherwise become large and unwieldy.
Let's take a look at how groups work in Rulebricks, and how you can use them to organize your decision tables.
Creating a group
To create a group, select the conditions you want to group together, and select the "Group" icon from the toolbar. If you are confused which icon is the "Group" icon, hover over the icons to see their tooltips.
Explore the group's settings
Once you've created a group, you can open the group settings menu by clicking either the group indicator, or any row's settings icon within the group.
You should see a menu that allows you to configure the group's hit policy, and other settings.
Configure the group's hit policy
The hit policy determines how the output of the decision table is calculated. They are outlined in the menu you just opened, and we'll cover them in more detail below.
For each satisfied condition in the group, the Fill Values hit policy will identify any new non-null response dimensions and add them to the output object.
For example, if you have a group with two conditions, and the first condition returns a percentage discount of 10% but a flat price of null, and the second condition returns a flat price of $5 but a percentage discount of null, this policy will return an object with both the percentage discount and the flat price. This is useful when you want to create a decision table that incrementally updates response data dimensions (i.e. first you have a set of rows that decides what the "percentage_discount" should be, then you have a set of rows that decides what the "flat_price_discount" should be, and you want to return both).
Add Values in Rulebricks groups is similar to Fill Values, but rather than simply filling in non-null response dimensions, it will actually try to add non-null values together. This is useful when you want to return a single value that is the sum or score of all the values from multiple response rows satisfied in the decision table.
Compute Values is the most advanced hit policy in Rulebricks and allows you to define a custom accumulation pattern for each column. This policy is useful if you want to add up the results of multiple satisfied rows for some columns, but not for others. It's also useful if you'd like more control over how you combine responses from multiple satisfied rows, rather than just adding up everything. This policy also allows you to write your own accumulation function, should you need it.
A good example of this policy in action can be found on this use-case page (opens in a new tab).
You can visually identify groups in your decision table by the group indicator, which is a small colored circle that appears to the left of the group's conditions. Different groups are assigned random unique colors.
Rule-Level Hit Policy
In addition to group-level hit policies, you can set a hit policy for your entire rule. Open Rule Settings by clicking the settings icon in the rule editor navbar, and find the Hit Policy option under the Execution tab.
By default, rules use First Match. When multiple rows are satisfied by a request, only the first satisfied row (or the first satisfied group) determines the response, and any other matches are ignored. Selecting Fill Values, Add Values, or Compute Values instead combines the responses of all satisfied rows in your decision table using that strategy, exactly as the equivalent group hit policies do. Rows are always combined in the order they appear in your decision table.
A few things to keep in mind:
- Groups keep their meaning. If your rule contains groups, each group's satisfied rows are combined first using that group's own hit policy. The rule-level hit policy then combines those group results together with any other satisfied rows, in table order.
- Priorities still apply. If satisfied rows or groups have different priorities, only the highest-priority matches are combined. Priority continues to select which rows are in play, and the hit policy decides how their responses combine.
- Priority isn't configurable at the rule level. Priorities are only meaningful for subsets of rows competing within a rule, so the rule-level setting is purely a hit policy.
- Like other execution settings, the rule-level hit policy takes effect as soon as it is saved.