Business rules are manually-created formulas for rewriting queries. This is the most versatile strategy for creating custom query rewrites. It supports a variety of conditions and actions to address a wide range of use cases. When you need a very specific query rewrite, this is the best strategy. Business rules are applied in the Apply Rules stage of the query pipeline.
When a query triggers a business rule, then the business rule overrides any query rewriting strategies that conflict with it.

​
Rule conditions

A rule can have one or more conditions which define the criteria that trigger the rule’s actions. The + Add Condition button allows you to add a condition type to a rule, and you can add multiple conditions to the same rule. When multiple conditions are defined, they are joined by Boolean OR, that is, one or more conditions must be met in order to trigger the rule. Tips:
  • Since the Query condition can be configured with multiple criteria, you only need one condition of that type per rule.
  • To configure a rule that always fires with every query, select no conditions.
  • Multiple conditions of different types are joined by Boolean OR, that is, the rule is triggered when one or more conditions of different types are met.
  • By default, multiple field value conditions are joined by Boolean OR. To use AND so that all field value conditions must be met, go to the Apply Rules query pipeline stage and de-select Partially Matched Filter Queries Will Trigger the Rule.
Condition types are described below:
  • Dates The rule is applied only during the specified date and time range, which can be open-ended.
  • Query The rule is applied when the query terms match using one of the following methods:
    • Keywords The query term exactly matches one or more specified query terms. Keyword matching is case-insensitive. Multiple keywords can be specified with a comma delimiter.
      This is the fastest type of query matching.
    • Text The query term is matched using text tokenization. For example, “customer” matches “customer service” and “customer help”
      Enter one or more query terms to match using the selected method. When you enter multiple terms, any match against one of them will trigger the action (logical OR).
  • Field Value This condition type identifies a predefined field name and value that may be present in the Solr filter query parameter (fq), such as an “on_sale” field whose value is “true”. In that example, your rule could block results whose “on_sale” field value is “false”.
    Field Value conditions require whole-field exact matches and are generally called programmatically, by a link to a category or a click on a facet.

​
Rule actions

A rule can have one or more actions that are triggered when the rule’s conditions are met by the incoming query.

​
Built-in rule actions

  • Boost List
    Boost particular items to the top of the results.
    For example, boost gift items on sale to the top of search results during the first weeks of December.
    To use the *Query Elevation Component, you must first configure your Solr cluster using the instructions below, then select Use Query Elevation Component. Note that query elevation does not boost scores.
  • Banner
    Display a user-defined banner message when the rule fires.
    For example, a search for “office dvd” could return a results page that includes a special banner that advertises “The Office DVD boxed set: Now 50% off”.
  • Bury List
    When the condition is met, the rule down-ranks all the documents with the specified field values for the given field name. Use this action when you want to minimize certain results without blocking them.
  • Block List
    Suppress one or more items from the list of results.
  • Set Facets
  • Set Params
    This rule type corresponds to the Additional Query Parameters stage and permits the complex modeling of a rule.
  • Filter List
    Change the results so only a specified set of content is shown.
    For example, a search for “kids movies” could return only the titles whose MPAA_rating field matches “G” or “PG”.
    To use the Query Elevation Component, you must first configure your Solr cluster using the instructions below, then select Use Query Elevation Component. Note that query elevation does not boost scores.
  • Redirect
    Send users to a different URL instead of the search results.
    For example, a search for “black friday” could redirect users to a special sale page instead of a list of products that match “black” and “friday”.
  • Boost Attributes
    This action boosts documents with specific attributes by adding the bq or boost parameter to the incoming Solr request and executing a boost query.
    When the condition is met, the boost query is executed and the docs returned from the boost query are boosted in the results.
    For example, this action can be used to boost items where color="red" when the incoming query contains “red”.
  • My Custom Rule
    Select an alternate query pipeline that implements special processing for this rule. See below for more details.

​
Query Elevation Component for Rule Actions

Fusion AI currently supports the use of the Use the Query Elevation Component (QEC) with boost lists and filter lists. You must configure Solr in order to enable the QEC option.
  1. Create an XML file named elevate.xml in the same directory as the solrconfig.xml file. Use the following as the contents of the file: 
    <?xml version="1.0" encoding="UTF-8" ?>
<elevate>
</elevate>
Although it will not be accessed for the elevation process, Fusion requires this independent elevate.xml file for the use of built-in rule actions with QEC.
  1. Add the following in the elevator searchComponent: 
    <str name="config-file">elevate.xml</str>
  2. Add elevate as a ‘last component’ part of the select handler in the solrconfig.xml file. If a last-components array is not already defined, create it at the end of the select handler’s configuration. If one is already defined, add <str>elevator</str>. 
    <arr name="last-components">
    <str>spellcheck</str>
    <str>elevator</str>
</arr>
  3. When you Create a new Business Rule, check the USE QUERY ELEVATION COMPONENT checkbox to use elevation.
rules qec
ImportantThe Query Elevation Component only elevates documents within the query rewriting rules engine by the document id field. Ensure id is entered in the “FIELD NAME” option.

​
Custom rule actions

You can create custom actions for rules by creating a special query pipeline that implements the desired functionality, then creating a custom rule using the UI or the API.

​
Query pipeline stages for rules

These stages are part of the default query pipeline:
  • Apply Rules Rules query stages in the query pipeline This stage looks up rules that have been deployed to the response rewriting are applied by the Modify Response with Rules stage later in the pipeline.
  • Modify Response with Rules
    Most rules operate on the request, but some rule types, such as banner rules or redirect rules, do their work when the response comes back. The Modify Response with Rules stage applies those rules to the response. For example, a banner rule can add a banner URL to the response before returning it to the client.
Generally, if you are using rules then you need both of these stages enabled in your query pipeline. The Apply Rules stage must come before the Solr Query stage, while the Modify Response with Rules stage must come after the Solr Query stage. Disabling or removing the Apply Rules stage will disable rules entirely, while disabling or removing the Modify Response with Rules stage will disable only the rules that perform response rewriting, if any.

​
Rules on response signals

Response signals capture a list of rule IDs that match the query, in a multi-valued field named rule_ss. This allows for downstream analysis on rule activity using SQL, App Insights, or a custom Spark job.

​
Rules and experiments

The easiest way to integrate rules and experiments is to create one query pipeline with rules enabled and one without, with all other settings constant between the two pipelines. The pipeline without rules enabled must be configured manually. To create an experimental rule, use tags on the rule and set the tag in one of the variant pipelines.