Business rules can start to overlap with each other, resulting in a complex set of configuration rules. In some cases, the choices available in one field depend on not just one preceeding choice, but many choices. When dealing with complex relationships, try the "truth table" technique. "Truth tables" can help you control field options based on multiple other fields simultaneously. This technique can summarize the most complex logic in an easy-to-manage way.
This is part of a series of help documents on how to use option filters. For the full list, see the "Related Articles" section below.
Before you begin...
- Be familiar with the basic concept of option filters, as described on theOption Filter page.
- Complete the "Option Filters 1: Basic Walkthrough: Segmenting a long list of options" walkthrough, so you have a working example of an option filter driven by a local table of data.
- Complete the "Option Filters 2: Using Query Rules" walkthrough, so you understand how to apply Snap logic to a simple option filter.
- Complete the "Option Filters 3: Expressing complex logic in a megatable" walkthrough, so you're familiar with that technique. In many cases, that technique is more appropriate than a truth table, and is worth investigating first.
Overview
Defining the problem
You've already learned how option filters are an easy way to summarize field dependencies: the selection your user makes in one field can change the options presented in a second field. But what if it's not just one field that changes the options? What if it's the unique combination of two or more fields that drive the options in a third? The megatable technique is one way to store these logic combinations, especially if the combinations result in a logical loop. It is easy to understand and maintain, and every possible combination (in the scope of this megatable) is clearly listed. Simple configurators can be based on one megatable, or multiple megatables for ease of maintenance.
Multiple dependencies
A quick solution: The "simple" source, with Snap rules to update field options
A scalable solution: Define field options through a "truth table"
However, the megatable technique has limits. Increasing the scope of the megatable by adding more fields to it – or adding more options for the fields – results in exponentially more information your megatable must maintain. This is normal, and part of the design of the megatable. As we saw in the megatable walkthrough, the best way to manage a huge megatable is by clearly defining a narrow, focused scope. But what if your field relationships are complex and you have a lot of them?
A side note. Before we look at truth tables, you should remember that Snap rules can add or remove choices from field options. This can be a fine way to apply a small business rule to an otherwise straightforward set of choices. Since the options property of the field is just anarray, you can add and remove items from it using Snap array blocks or query blocks as well.
But this technique is limited, in that you must write Snap rules for each variation you need. And furthermore, the data is stored in code, not in a table that other business colleagues can easily maintain.
So if you have complicated dependencies, or so many of them it would be difficult to manage them all in a "mega table," try using a "truth table". It offers the flexibility of Snap rules with the easy maintenance of tabular data. The rest of this document describes the truth table technique.
Use Megatables First
In our experience, we've found that megatables can solve most, if not all, of your data mapping needs. Remember, the logic of a configurator can be driven my many smaller megatables, and those megatables can be the result of SQL joins of even smaller tables. Only if this architecture struggles to scale would you consider this second truth-table technique.
Let’s start with a simple example: a vehicle configurator. The business rules for our hypothetical vehicle configurator could be as follows: A vehicle has a specific use, and that use controls what wheel options are available:
- Vehicle Use options:
- 1-or 2- person commuter/urban vehicle (a smart car)
- 4-person vehicle for city/suburban use (a sedan)
- 4-person vehicle for country or off-road use ( Sport Utility Vehicle, or SUV)
- 2-person vehicle for hauling heavy loads (a truck/lorry)
- Wheel options:
- Light, fuel-efficient wheels
- Standard wheels
- Heavy-duty wheels for rough surfaces or heavy loads
- Rules:
- Light wheels can only be used for smart cars or sedans
- Standard wheels can be used for sedans or SUVs
- Heavy duty wheels can be used for a SUVs or a Truck
At a high level, these rules describe a simple relationship between two parameters: the "vehicle use" controls the choices of "wheel type". A drawing on a whiteboard could look like this:
To represent these rules, you could map together these options in a truth table. List the controlling field options across the top, and the dependent field options down the left side. When a combination of the two is valid, we place a “1” or “True” at the intersection of those two combinations:
Vehicle Use |
|||||
Smart Car |
Sedan |
SUV |
Truck/Lorry |
||
Wheel |
Light |
1 |
1 |
||
Standard |
1 |
1 |
|||
Heavy Duty |
1 |
1 |
|||
That truth table above is about the same size as the megatable version of the same information (shown below), but the truth table can be easier to understand by people who must maintain it. Your eye can easily scan the table and see a pattern, while that same pattern is not as apparent in the megatable version:
Vehicle Use |
Wheel |
Smart Car |
Light |
Sedan |
Light |
Sedan |
Standard |
SUV |
Standard |
SUV |
Heavy Duty |
Truck/Lorry |
Heavy Duty |
Benefits of truth tables
The first benefit: one field’s options can be based on more than just one dependency. You can use multiple other fields to control those options. And the combinations between the dependencies. For example, let's add on to our existing rules. Let's say the wheel options are dependent not simply on the use of the vehicle, but also engine type and region where it was sold. Our whiteboard drawing would look like this:
And our table would have some new columns, colored red and yellow here:
| Vehicle Use | Engine Type | Sales Region | ||||||||
Smart Car |
Sedan |
SUV |
Truck/ Lorry |
4-cyl Engine |
6-cyl Engine |
Europe |
North America |
Asia |
||
| Wheel Type |
Light |
1 |
1 |
1 |
1 |
1 |
||||
Standard |
1 |
1 |
1 |
1 |
1 |
1 |
1 |
|||
Heavy Duty |
1 |
1 |
1 |
1 |
1 |
1 |
||||
Read the table across, then down.
- The first row says that in the field "Wheel Type", the option "Light" will appear only if three facts are true:
- The vehicle use must be Smart Car or Sedan.
- The engine type must be 4 Cylinder.
- The sales region must be Europe or Asia.
- Look at the second row: this logic is simple. The "Wheel Type" option "Standard" will appear only if the vehicle use is Sedan or SUV. This is for all engine types and sales regions.
- And the third row? The "Wheel Type" option "Heavy Duty" is available only for SUVs or Trucks with 6 cylinder engines. This is true across all sales regions.
Logic beyond true and false
Another truth-table benefit: the logic in your fields can be more complex than just true or false. You can use comparison terms (greater than or less than), or use dates or text strings as well. Here’s an updated truth table for our vehicle configurator example:
Snap blocks required for Truth Tables
Example 1: one field
Example 2: multiple fields
| Vehicle Use | Engine Size (cyl's) | Sales Region |
Sales Date |
||||||||
Smart Car |
Sedan |
SUV |
Truck/ Lorry |
Min |
Max | Europe |
North America |
Asia |
|||
| Wheel Type |
Light |
1 |
1 |
4 | 4 | 1 |
1 |
any |
|||
Standard |
1 |
1 |
4 | 6 | 1 |
1 |
1 |
any |
|||
Heavy Duty |
1 |
1 |
6 | 6 | 1 |
1 |
1 |
2019 |
|||
Heavy Duty |
1 |
6 | 6 | 1 |
1 |
1 |
2020 |
||||
In the truth table above, note two changes:
- The engine size is now a comparison operator, defining a range between two fields. It expresses the same business rules as before.
- A new date column has been added to store how the product offerings change over time. Look at the last two rows: they show how in 2019, heavy duty wheels are available for SUVs or Trucks. But in 2020, heavy duty wheels are only available for Trucks.
The strength of truth tables is the ability to express more complex business logic in a way that’s easier for people to read and maintain than megatables. The information density of this technique is still easy to read. Consider how much time it took you, as you read this document, to understand the truth table examples. At this abstract level, there is no computer programming to learn. There are only tables to scan visually. In most implementations, the truth tables can be given to the product manager as spreadsheet files, like an Excel chart. Explain the spreadsheet the first time, and guide them through their first few changes, and you may find the product manager can update the spreadsheet on their own. Your job as a Epicor CPQ Company Administrator is to simply copy the data from their spreadsheet into a CPQ table, a quick process unlikely to introduce errors.
Truth tables do require Snap blocks in the option filter to read this logic table. But the code you write is set up once, and does not require constant editing. All that editing is pushed into the table. Let's see how our example tables above would be implemented in Epicor CPQ.
Vehicle Use |
|||||
Smart Car |
Sedan |
SUV |
Truck/Lorry |
||
Wheel |
Light |
1 |
1 |
||
Standard |
1 |
1 |
|||
Heavy Duty |
1 |
1 |
|||
| Example 1: Epicor CPQ Table |
|---|
|
| Example 1: Epicor CPQ Option Filter |
|---|
|
Remember, our table has the input options listed across the top as columns, with the resulting field options running down the left as rows. So,
- for each input column in our table, we create an IF block that "guards" it. Its logic is added to the query only when necessary.
- Since all four of these columns represent options for the same field, we use an AND block to group together those four IF blocks.
At first, the option filter query may seem complex. But note that there is no business logic in the query. It's a structure that simply links the table logic to the configurator's fields. If business rules change, chances are the change is simply an edit to the table. The query rule stays untouched. While the query rule can be a little effort to create, it's easy to maintain going forward. It often requires no maintenance at all.
| Vehicle Use | Engine Type | Sales Region | ||||||||
Smart Car |
Sedan |
SUV |
Truck/ Lorry |
4-cyl Engine |
6-cyl Engine |
Europe |
North America |
Asia |
||
| Wheel Type |
Light |
1 |
1 |
1 |
1 |
1 |
||||
Standard |
1 |
1 |
1 |
1 |
1 |
1 |
1 |
|||
Heavy Duty |
1 |
1 |
1 |
1 |
1 |
1 |
||||
| Example 2 Table |
|---|
|
| Example 2 Option Filter |
|---|
|
The query block can look overwhelming! But it is the same structure as before. Here, we summarize multiple options from multiple fields, so it starts to look longer. But the structure is simple:
- Each option for a field is wrapped with an IF block, which translates the datatypes and values of the fields into those of the table.
- Each field has its options wrapped together with an AND block.
- The filter itself wraps all the separate fields together with an OR block.
Of course, each use is different, but you'll find this same pattern over and over. For example, depending on how you gather info from your customer in the UI, and how you gather info from your subject matter expert in the table, you may find the field options not protected by an IF block can be wrapped together with an OR block and the filter itself wraps the separate fields together with an AND block. Test your design.
Table 3: beyond true and false
| Vehicle Use | Engine Size (cyl's) | Sales Region |
Sales Date |
||||||||
Smart Car |
Sedan |
SUV |
Truck/ Lorry |
Min |
Max | Europe |
North America |
Asia |
|||
| Wheel Type |
Light |
1 |
1 |
4 | 4 | 1 |
1 |
any |
|||
Standard |
1 |
1 |
4 | 6 | 1 |
1 |
1 |
any |
|||
Heavy Duty |
1 |
1 |
6 | 6 | 1 |
1 |
1 |
2019 |
|||
Heavy Duty |
1 |
6 | 6 | 1 |
1 |
1 |
2020 |
||||
| Example 3 Table |
|---|
|
| Example 3 Option Filter |
|---|
|
Instead of showing the entire query block, here we just show the two changes:
- The previous Engine Size logic is now replaced with a comparison operator. The first AND block ensures that only rows with an appropriate engine size are considered.
- A new Sales Date logic is added, also with an AND block ensuring that only rows with an appropriate date are considered.
Since the field "Engine Size" is a number, and the table columns "EngineSizeMin" and "EngineSizeMax" are also numbers, we don't need an IF clause to help us convert values. We can simply compare them directly.