Option Filters 2: Query Rules

Article last updated: January 22, 2025 13:14

Option filters are a simple yet powerful way to express complex business logic. While referring to a matrix of options solves many problems, you may want to filter the data in that matrix before it is offered to your user. Apply business rules to your matrix via a query rule, very similar to the way SQL works.

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.
Know the basics of Snap, our programming language, and have already built some simple value rules or validation rules for experience in using Snap.
Complete the "Option Filters 1: Basic Setup" walkthrough, so you have a working example of an option filter driven by a local table of data.

Overview

In this walkthrough, we will:

Review the basic matrix of choices from the previous walkthrough.

In the previous walkthrough, we learned how to represent a table of data as a series of fields, one for each column. Since we represented the entire table, there was no filter in place, and no Snap code was required.

Data	User Interface
Three columns of data...	...appears as three fields in the UI.

Apply a business rule to filter the choices presented to your user.

Using the entire matrix of data is nice, but you may want to filter out some of the data in your table. Consider the following scenario. Our supply chain department contacts us, saying "All synthetic materials are on back-order. Do not show these materials until further notice." We have two solutions:

We could add a validation rule, warning anyone who sets the Family field to synthetic that these products aren't available. The benefit: our users are aware we usually sell these products, but not today. The drawback: we are offering something which we cannot fulfill.
We can add a query to our option filter, so synthetic choices don't even appear. The benefit, we don't give our users errors for simply selecting a product that's wrong... at least for today.

For the purposes of this exercise, let's do the second option. Let's add a query.

	Task	Walkthrough Example
1	Add a query to your option filter.	In the Administrator Interface, open your configurator, and click on the option filter you would like to update. > The properties of that option filter appear. Change the "source" property of the option filter from "table" to "query". > A new "Add Query Rule" button appears. Click that button. > In the design tree, a new "Filter Rule" entry appears, indented beneath your option filter. Since that rule is empty, your option filter will show a red warning symbol, letting you know it's not completely defined. Any fields which depend on this option filter that is incomplete will also show warning symbols. Don't worry: adding logic to your query will solve the problem, and all those red indicators will disappear. Click that new "Filter Rule" entry in the design tree below your option filter. > The right-hand portion of the administrative interface changes into a Snap workspace. There's no green "start" block, because we're not writing code that runs in steps, we're writing a single query which is understood all at once. You'll see the block we need to fill is called "Fill option filter with query of"
2	Define the source of your query.	If you click on that "Fill option filter..." block, a group of buddy blocks will appear to the right. Find the "Table" block, and drag it into place. Select the table you want.
3	Test your query.	This is a very simple query. It's getting all the data from the same table, with no filters or logic in place yet. Therefore, it should behave just like it did before you started step 1. Run your configurator to be sure.
4	Add logic to the new query.	Again, click on the "filter rule" listed below your option filter to edit the filter. To meet the business rules of our scenario, we'll edit the query block: Click the "option filter" category in the toolbox. Drag the comparison block (it says "table column") out of the toolbox, and onto the open white workspace somewhere below your query block. We want to add a "where" clause to our query. Click the "+" symbol to mutate the block, and choose "where". > The "Where" slot appears. Drag your comparison block into place, add a text value block from the toolbox, and edit the logic so it reads like this:
5	Test the new logic in your query.	Run your configurator. You should notice that no synthetic items appear. Remember, comparisons are exact, so it's easy to make these mistakes: Exact means case-sensitive. "synthethic" is not "Synthetic". Exact means no trailing whitespace characters that can be hard to see. For example, if you have a space or a return character after the "c" in "synthetic"

Use boolean logic to incude a second business rule.

Let's continue our scenario. What if supply chain contacts us again, saying "All metallic materials are also on back-order. Do not show synthetic or metallic materials until further notice." We can do that!

	Task	Walkthrough Example
1	Add boolean logic to the query.	Again, click on the "filter rule" listed below your option filter to edit the filter. To meet the business rules of our scenario, we'll edit the query block: Click the "option filter" category in the toolbox. Drag the logic block (it says "and") out of the toolbox, and onto the workspace. Drag your blocks (be smart and clone an existing block by shift-dragging it) until you see this:
2	Test your new query.	Run your configurator. You should notice that no synthetic or metallic items appear.

Add conditional logic based on information from the configurator itself.

The fast changes you made are causing quite a stir in the Sales Department. After some discussions with Supply Chain, they all have agreed to the following: if a new "Priority Request" field is set to true, then allow the user to select metallic materials. But metallic should be hidden otherwise.

	Task	Walkthrough Example
1	Create the new field.	In your UI, create a new boolean field to track if the user is a priority user. Give it the name "fIsPriorityRequest", and either a toggle or checkbox control. (In a real application, we would not leave this visible and easy for everyone to edit.) You can give it a shorter label, such as "Priority".
2	Add this new field to the query.	You can refer to any field in the configurator using the GetField block. And you can use conditional logic within your query, to make certain parts of it be applied or be ignored. Update your query logic: Click the "option filter" category in the toolbox. Drag the conditional block (it says "if") out of the toolbox, and onto the workspace. Find the "GetField" block (try typing "getf" next to the magnifying glass to see it), and drag it into the workspace. Drag your two new blocks into the query, like this:
3	Test your work.	Now, depending on the status of this new true/false field, choices will appear or disappear.

Queries can become complex

By combining these three blocks in various combinations, you can create queries to satisfy the most complex business needs. If you find your queries are getting too difficult to manage, consider these:

Consider "chaining" your option filters
Instead of having all your logic in once place, you can factor your logic into more manageable sections.
Consider other option filter techniques, like the "truth table"
Other option filter techniques let you store business logic in tables, rather than in Snap code. These logic tables are often easier to understand and manage.

See the related articles below for more information.