A typical processor has two main parts:
- One that contains elements and is to be executed if the right conditions are met.
- The other that contains request filters whose purpose is to determine if the processor should be activated and if so, to transfer platform data into the service evaluation context (slot values, intent name).
Simply put, the first part gets executed only if the processor is successfully matched in the second part.
You can see a Simple Processor’s layout in the image above. It has one OK flow container which gets executed if the request filters in the container of the same name get matched.
More specialized processors might have multiple OK flows. They also might omit request filter definitions completely and use pre-defined built-in logic. Such is the case with the Yes/No Processor which has two OK flows and no Request Filters container.
You can stack several processors in a single block. The block will use the first processor which matches the current request. Not only the block’s processors but the service processors as well are taken into account when trying to match a request. If none of the block’s processors get matched, the system will then try to match one in the __serviceProcessors special block.
If you haven’t already, you can read more about special blocks in the Special block roles guide.
