Option filters are a simple yet powerful way to express complex business logic. If your business rules contain logic loops or other complexities that are hard to express in our Snap language, you can often express that logic more simply by using a table format.Express very complex business rules in a table by listing every valid set of options in a table.
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 the Option Filter page.
- Complete the "Option Filters 1: Basic walkthrough: Segment 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: Use query rules to apply dynamic logic" walkthrough, so you understand how to apply Snap logic to a simple option filter.
Overview
In this walkthrough, we will:
Review a complex set of dependencies
You're already familiar with a simple set of dependencies, as described in the previous walkthrough. In that simple example, you saw how the data and relationships for 3 fields are described in a table. The "family" field controls the options shown in the "group" field, and the "group" field controls the options shown from the "material" field.
| Data | User Interface |
|---|---|
Three columns of data...
|
...appears as three fields in the UI.
|
Visually, those dependencies can be expressed with this diagram:
That's a straightforward setup.
But other dependencies can be complex and interrelated, like this:
Complex dependencies like this can sometimes be easiest to create (and more importantly, to maintain) using a table rather than code.
The philosophy here is to define, explicitly, every possible valid combination of choices for a portion of your configurator. By defining this logic beforehand in a table format, you gain several advantages:
- First and foremost, a table makes communication with the rest of the business easier. When trying to understand a set of rules, many people feel overwhelmed. They can be hard to describe. But when those rules are expressed in a table format, they can be much easier for business colleagues to understand and manage. In fact, you may find that after you create the logic table in Excel, you can hand off the maintenance of that table to the subject matter expert (SME) in that area.
- Tables can also help gather up all those "one-off" unusual business rules into one easy-to-manage location. Rather than having many separate rules, which may begin to conflict with each other as your application grows over time, you can store all the logic in one place.
But tables, also have weaknesses:
- They can get large quickly, and sometimes the thousands of rows you use to express logic in a single table could be replaced with a 2- or 3-line query rule.
- Don't rely on option tables to solve all the challenges of creating a configurator.
Let's look at an example configurator project, and see how the option table technique can help us. For our walkthrough, we'll use a hypothetical scenario at a company who makes flavor dispensers used in food manufacturing. From thick flavors like mayonnaise to runny flavors like vinegar, the flavor dispenser can precisely measure and produce them all... if it's built correctly. Each flavor dispenser has tanks and pumps that make it work. Our job is to create a configurator that encodes all the business rules, so our customers can use our tool to build the perfect dispenser to help manufacture their food.
Every project is different, but here's one sample process to get started:
| Task | Walkthrough Example | |
|---|---|---|
| 1 | List all the fields. |
From interviews with manufacturing, we have this list of fields
|
| 2 | Given each field, gather the options for each | In our example, the fields Application, Input Tank, and Exit Tank fields have only one value, and are therefore out-of-scope for this walkthrough. Here are the options for each remaining field. Pump fields have a numeric size, and the prefilter field has a text status.
|
| 3 | Given those fields, gather the field-level relationships between them. Try to get an example for each. |
For our example, an interview with Manufacturing gives us these business rules and examples: Rule 1. At least one pump must be selected. If only 1, then it must be the first. Rule 2. The same pump size cannot be set on 2 pumps in a configuration. Rule 3. If the sum of the pumps >70, a prefilter is required. (Later, we will drill down past the field level, and start to think about the option-level relationships. But field-level is enough detail for now.) |
| 4 | Optionally, draw the fields and their dependencies as a diagram. | Creating a drawing can help you understand the big picture, and can also help you understand the order of the fields in your future user interface. There are many tools available that you can use, chose your favorite and translate the list of dependencies into a graph, like this: |
Determine that these dependencies are best expressed as a table
Not that we have all our fields, the choices of those fields, and a high-level dependency map the next step is to determine which dependencies may be best expressed in a table. For example:
- If you don't want your users to see invalid combinations.
While you can use a validation rule to highlight a combination of options that is invalid, in some cases you don't even want to show an invalid combination. When a user adjusts one selection which invalidates some other selection, you may want that other invalid selection to simply disappear, or be replaced by a valid choice, rather than present an error or warning on-screen.
- If your dependencies are in a logical loop.
Example: if field A depends on B, and B depends on C, and C depends on A. This is a logical loop.
- If your dependencies have complex field-level mappings.
Given our example above, we clearly see some logical loops between the fields for Pump 1, 2, and 3. The prefilter is also dependent on those fields as well in another logical loop. It seems a table is a useful solution to this design.
Define the scope for our table
You don't need to create one option filter for your entire configurator. Rather, focus on a group of fields in your configurator which are logically tightly related, and try creating an option filter for just that group. In our example, we'll create an option filter that will describe all the choices possible for the 3 Pumps and the Prefilter. The visualization tool helps us easily define our table scope:
Once we resolve the complex logic in the highlighted area, the rest of the fields will be simple. For example, we can control the choices presented in the "Exit Tank" through the query rule technique shown in the previous walkthrough.
Given this clearly-defined scope, let's get started!
| Task | Walkthrough Example | |
|---|---|---|
| 5 | Describe any option-level relationships in a granular way |
Given the field-level relationships you expressed as arrows above, now drill down to the options within those fields. Describe those relationships in a specific and granular way, such as "field X controls option Y in field Z". This means you may need to break down one general business rule into multiple specific relationships. For example, rule 3 above can be decomposed into 3 more detailed rules: Rule 3. If the sum of the pumps >70, a prefilter is required. becomes Rule 3a. If the sum >70, then "Optional" is illegal |
Many option-level dependencies? Try a truth table
In our example, we don't have many option-level dependencies between fields. If your analysis for your own implementation starts to show many of these dependencies, learn about the "truth table" technique. It may be a better fit for your business logic than using a table.
Build a list of of all possible option combinations
List out of every possible combination of the choices provided. While there are many tools available to help you create such tables, (see the list of links at the bottom of this walkthrough), for speed and simplicity we've done this step already and have documented the remaining steps in this Excel worksheet:
Remove those combinations which are not allowed
Useful Resources
Test what remains in the table to confirm it meets the original business needs
Related articles
list of options.pump exercise.xlsx
Click that link once to open a preview window. In the preview window, click...
the download icon to download the file to your own computer, and
the close icon to return to these instructions.
We have also put some business logic into the Excel chart. Of course, we can also put this logic into the option filter's query rule, or otherwise store and manage it in Epicor CPQ.
Epicor CPQ does not require any other tools to work: it is completely web-based. However, in this example we want to show how you can create a file that helps your subject matter expert manage their own business logic, using a tool they're comfortable with. Here we use Excel, and place some business logic there, as a way of inviting our SME to take on ownership of this logic and hopefully manage it independently without our help going forward.
| Task | Walkthrough Example | |
|---|---|---|
| 6 | Given all the choices for the fields in scope, create a list of all possible combinations. |
Open tab 1 of the excel file above: you'll see the fields and the options for each. Open tab 3 of the excel file: you'll see how every possible combination of those fields has been created. See the related resources listed at the bottom of this walkthrough for more information. |
Every situation is different, so the technique used here may not be ideal for you. But let's talk about the steps used in creating tab 4 in the worksheet, where our table and our field-level business rules are shown together. (If you haven't defined the high-level business needs as specific field-level business rules, complete that task first. It may be hard to proceed otherwise.)
| Task | Walkthrough Example | |
|---|---|---|
| 7 | See if a field-level rule can be met by adding or removing choices from your fields. | In our example, Rule 1 can be met by simply removing the "0" choice from Pump 1. Now, the user is forced to select a pump size for Pump 1, instead of selecting zero (meaning no pump). This also makes our list of combinations. |
| 8 | For each remaining detailed field-level rule, create a column next to your product data. The column will result in a true or false value, showing if the rule is met or broken. | Rule 2 says that no two pumps can be the same. We can express that in an excel formula on tab 4 that shows if the rule is broken. Rules 3a, 3b, and 3c state what prefilter options can be shown. Again, each of those are expressed as a separate column on tab 4. Note how each rule is managed separately. This makes managing the table easier when business rules are updated in the future.
|
| 9 | Now that each row has a set of rule flags, summarize them. | In our excel file, look at column M on tab 4. It counts up how many rules are broken for each row in our list. Those rows which break no rules are highlighted in green, and they are the rows we want to keep. |
| 10 | Extract the rows which break no rules into a Epicor CPQ table | Tab 5 is this final step. Tab 5 is just the same as Tab 4, only we've applied a filter to column M, showing only those rows which break no rules. Select these rows by copying them (B3 to D282), and pasting them into a Epicor CPQ table. This is your table. |
| 11 | Use that table to build your option filter. | Follow the steps in the first option filter walkthrough to create a table, define an option filter, and connect your fields to the option filter. |
We have a working prototype! Share it with your business partners, and invite their feedback.
- If they want to add or remove options from fields, recreate your list of possible options. Then ensure the business rules are still being applied to all rows, and extract your table data again.
- If they want to change or edit business rules, just do so on that page of your chart, and extract your table data again. Since you've created a modular way to keep each rule separate, you can easily add, edit, or remove business rules.
- Create your list of possible options quickly, online, using this tool.
- Create your list of possible options directly in Excel by following steps described in one of these resources.
- Create network graphs automatically using NodeXL Basic. The Basic version is free and a great introduction to this useful tool.