Plan for query pipelines

This is for:

Developer System Administrator

To allow your ServiceNow end users to benefit from Coveo™ for ServiceNow, you must add Coveo for ServiceNow widgets to your ServiceNow instance. These widgets are meant to improve your end users’ journey by allowing them to search multiple sources of content through a single search box, providing them with the most relevant content, and proactively recommending items in which users with a similar profile and journey were interested. The next steps of this deployment guide cover the process of adding the Coveo for ServiceNow widgets to your instance.

When an end user interacts with a Coveo for ServiceNow widget, this widget sends queries to your Coveo index, which then returns matching items to display in the widget (see Architecture). To reach the index, queries transit through a query pipeline. A query pipeline is a container filled with rules and often associated with Coveo Machine Learning (Coveo ML) models that either modify queries before they arrive to the index or apply to the results returned by the index before they’re displayed in your Coveo for ServiceNow widget (see What’s a query pipeline?).

This article explains how you must plan your widget deployment with query pipelines in mind.

Widget deployment process overview

The process of deploying Coveo for ServiceNow widgets and linking them to a pipeline is the following:

  1. Determine how many query pipelines you need.

  2. Establish a widget naming convention.

  3. Add a widget.

  4. Add or edit the corresponding pipeline to link it to the widget.

  5. Further configure your pipeline to handle the features specific to this widget.

  6. Repeat steps 3 to 5 with the next widget.

Determine how many query pipelines you need

In general, it’s best to create a query pipeline per audience or end-user segment. For example, if you add Coveo for ServiceNow widgets to both your customer portal and your employee intranet, you have two audiences: your customers and your employees. You should therefore create two pipelines, as these two audiences must find different content through your widgets. Different content typically requires different sets of query pipeline rules, so it’s best to organize the sets separately. The number of widgets deployed for each audience is irrelevant; if two widgets serve the same audience and purpose, they should be linked to the same pipeline.

However, if two audiences happen to need several similar pipeline rules, it may actually be more efficient to link all widgets to the same pipeline. Maintaining a single pipeline is often easier since you don’t have to duplicate rules from one pipeline to another. In this scenario, if a rule must apply to only one of the audiences your pipeline serves, you can use a query pipeline condition to ensure that only this audience’s queries are affected by the rule (see Manage query pipeline conditions).

In short, there’s no formal rule as to the number of pipelines you should create with regard to your Coveo for ServiceNow audiences. We recommend that you find a balance between creating multiple pipelines and therefore having to duplicate many rules, and creating one pipeline that covers too many use cases with a large number of conditions. You should aim for an approach that makes sense to you and that’s simple to understand and maintain.

Establish a widget naming convention

Before deploying widgets, it’s essential to establish a naming convention to use when adding Coveo for ServiceNow widgets to your ServiceNow instance. This naming convention will prove useful when adding query pipelines or query filters and associating them to the desired widgets.

There are two options you can use to name Coveo for ServiceNow widgets. These options are Scope and Component.

Tip
Leading practice

We recommend that you base your naming convention on the audience and the widget type. In the Scope field, you should enter a keyword identifying your audience, while the Component field should specify the type of widget you used.
Example

You decided to add widgets to your customer portal and employee intranet. Therefore, in the Scope field, you enter CustomerPortal or Intranet, depending on where you added each widget.

In the Component field, you enter Recommendations for Recommendations widgets, CaseDeflection for Case Deflection widgets, etc.

In short, for a Searchbox widget in your intranet, you enter Intranet in the Scope box and Searchbox under Component, and so on for other widgets.

If you don’t want to follow this naming convention, ensure to pick descriptive names that can be easily remembered when creating query pipelines and query filters.

However, the Scope and Component options are independent. This means you could leave the Component box empty so that all widgets in the specified scope are targeted when you make changes to query pipelines or query filters. Conversely, you could decide that you don’t need a scope and use the Component option only. In such a case, all components would belong to the default ServiceNow scope. These are however advanced ways to identify your widgets, and we recommend that you provide a scope and component when starting out with Coveo for ServiceNow.

To name a widget you added to a ServiceNow page, access its customization options, and then fill in these fields according to your naming convention. To provide scope and component names for the Coveo Insight Panel, see Configure the Insight Panel.

What’s next?

Once you have identified your audiences and established a naming convention for your widgets, you can start adding Coveo for ServiceNow widgets to your instance and configuring the corresponding query pipelines. See Replace the Service Portal search page first.