Every Request filter first checks if it’s actually compatible with the user 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, we move on to the next filter if available, the process repeats itself, and so on.
Request filters usually have sub-components, readers that try to match and read the request data. You can learn more about request filters in general and their sub-components in our Request Filters guide.
The convo-core package has two request filters and two intent readers available.
Request Filters
Intent Filter
Intent Filter is used in combination with intent readers where you place one or more intent readers inside of it.
NOP Filter
NOP stands for no operation. The NOP filter is not connected to any platforms and doesn’t require configuration, and it’s great to use in the early, testing phase of your app development.
It has two settings you can choose from empty and match. The empty option doesn’t match any user input, while the match option matches all user input and the OK flow executes every time.
Intent Readers
Platform Intent
The Platform Intent reader requires you to define the same intent on your targeted platform.
The reader lets you rename an already existing intent slot and use the value under another slot name. You can also predefine slot values to be set, useful for intents meant to manage the cases when a voice assistant repeatedly mishears the user.
Convo Intent
The Convo Intent readers are part of the Convoworks Intent Model which automatically propagates intents to required platforms through the API. Unlike the Platform Filter case, you don’t have to create intents on the platforms manually.
The reader has the same properties as the Platform Intent reader, with one addition. It has the Required slots property for adding a list of slots that are required. If the requited slot is empty, the filter will not activate.
