1. Home
  2. Docs
  3. Publishers
  4. Component reference
  5. Request filters

Request filters

When a user makes a request using voice or text, depending on the platform, we either get raw text or evaluated user intent as information to work with.

Request filter first checks if it’s actually compatible with the given request. If it is, it will evaluate request data into the service context and other possible request filters won’t be taken into consideration. If it’s not compatible with the request, it will reject it and the next request filter will then check if it’s compatible and so on.

Request filters usually have sub-components, readers that try to match and read the request data.

In most cases, you’ll probably just use an Intent Filter which matches and reads requests from intent-based platforms like Alexa and Dialogflow. However, we also have text-based and NLP filters for chat platforms and chatbots.

You can even simultaneously use all filter types in the same block. This enables you to use the same logic for handling Alexa (strictly intent-based system) with FB Messenger and Viber which provide just raw text inputs.

The filter that matches the request first will be the only one executed. You can prioritize intents and their processors by rearranging them within the block.

If you’re using Intent Filters, it is recommended to use them together with the Convoworks Intent model which automatically propagates intents to required platforms through the API. In that case, you have to use Intent Filters paired with Convo Intent readers to match the desired intent. Read more about the ConvoWorks Intent Model here: Intent and entity model

If the intent contains slot values, the values will automatically be transferred to the service evaluation context under name result (e.g. ${result.answer}). You can also configure intent readers to rename some slot values (you can’t have the same slot name on multiple intents on Amazon!) or set some predefined value.

Renaming the slot is useful because of Amazon platform’s prohibition to use the same slot name in multiple intents. In such cases, you might end up with several intents carrying the same exact information but under different slot names.  You have the option to rename slots to have the same name on the filter reader level in the Convoworks Editor.

As for the predefined values, they are helpful to patch Alexa’s or Dialogflow’s speech misinterpretations. It’s a common situation that the platform misunderstands user speech, no matter how good your intent definition is.

For example, you keep getting the word “three” instead of the number “3”. You can solve this issue by creating a new intent with bad example phrases, catching them with an intent reader, and setting the desired value under the desired slot name.