BotNet Actions provide bot builders access to provisioned API connectors, CMS content, co-browsing commands, universal timeline elements, bot orchestration, NLP, and analytics. When a user enters an utterance and the corresponding intent is detected, the BotNet action will automatically be triggered.
[
{
"type": "executeApi",
"value": "apiFindSourceAccountByAccountNumber2",
},
{
"type": "flow",
"value": {
"id": "my-flow-id",
"type": "r2-avalanche-worker",
"deferRelease": true
},
},
{
"type": "markup",
"value":"<TimelineMessage> <TextMsg>hello</TextMsg></TimelineMessage>"
},
{
"type": "message",
"value":"hello"
},
{
"type": "messageVariance",
"value": ["hello", "hola", "howdy"]
},
{
"type": "pushBotToStack",
"value": "bot-name"
},
{
"type": "transferToBot",
"value": "bot-name"
},
{
"type": "Triggerintent'",
"value": "botName:::intentAlias"
},
{
"type": "setContext",
"value": { "name": "ServisBot" } //Context to set
}
{
"type": "goal",
"value":"goal-name"
},
{
"type": "hostNotification",
"value":"notification to send"
},
{
"type": "fallback"
}
]
Actions which send responses to the user (Message, Markup, messageVariance) can inject variables into this message from context. These are referenced using VTL syntax, e.g. ${myVariable}
.
The stored context for a user is available for use. This includes any keys you may have previously set in context, but also some conversational data:
{
state: {
history: ['previousintent1', 'previousintent2'], // previous intents visited
entities: [ // Matches for any custom entities you've defined, as detected by the SerivsBOT NLP worker
// An example entity
{
start: 0,
end: 25,
len: 26,
accuracy: 0.95,
sourceText: 'email@servisbot.com',
utteranceText: 'email@servisbot.com',
entity: 'email',
resolution: { value: 'email@servisbot.com' }
}
],
input: {
utteranceText : 'Utterance here', // What the user just said to trigger this intent
language : 'en', // The language we detected from the browser
isMobile : true // Whether the user is on a mobile device or not
}
}
};
Using this as an example, to reference what a user said from within an utterance, we’d setup a fulfilment action like so:
You said: "${state.input.utteranceText}" - let me see what I can find matching this.
You can use this BotNet action to send a plaintext response. If you want to send two or more consecutive messages, simply add more “Send a Message” actions.
Our markup language allows you to send a variety of widgets that are interpreted by our messenger. Examples include lists, calendars, carousels, and more. Learn how to use all the different types of widgets on our markup page.
It is possible to trigger a conversation flow as a BotNet action. When the flow is triggered, the bot will complete the actions within that flow automatically.
You can create an action flow in our designer where drag and drop nodes allow you to customize your conversation. The action flow must start with the actionStart node and finish with the actionComplete node. In between those two nodes, you can include any of the nodes that we offer on our canvas. All context assigned to the original bot will be included. However, it should be noted that the context is not passed back to the ServisBOT intent worker once the flow has completed its task.
In the json examples above, you can see the field deferRelease
. When you have the deferRelease
set to true you need to use the action complete node to remove this flow from the bot’s worker stack. Input to the bot will continue to be sent to this action flow until it is removed from the top of the worker stack.
To find out how to access all context check the context store. You will have access to any existing context collected thus far plus the following two pieces of information:
Existing context is available under msg.payload.context
An example of using the triggered intent is shown below:
Using BotNet actions we can trigger a goal anytime that the intent is detected. Goals are useful as a source of metrics. You can view how many times that goal was hit by navigating to the analytics tab on the left of our platform, clicking on the bot in use, and entering the name of the goal that you want to view. To use goals during fulfillment, add an action, select “Goal” as your BotNet action, and give it a unique name.
To trigger a host notification when an intent gets detected, add a fulfillment action, select “Host Notification”, and enter the relevant web page. If done successfully, you should see the host notification come up on the bot testing page in the “Notifications and Events” card when you trigger that intent.
By selecting “Send CMS Content” as your BotNet action, you can send CMS content to a user each time a specific intent is triggered. CMS is great for managing content that is used in many places. If a change needs to be made to the content, instead of having to edit it everywhere, you can simply adjust it in our CMS tab and the changes will automatically be applied everywhere that contains the content.
To use CMS as a BotNet action simply begin typing in the name of your CMS. Select the correct one when it appears. If you have not yet created the content in our CMS tab, see our CMS page for instructions.
Message variants are great for creating variety in responses that people may see often thoughout their conversations. You can input multiple suitable responses for your agent to send and then, during a conversation, one of the messages will be selected at random and sent to the user. To use message variants as a BotNet action simply add each response option on a separate line.
To temporarily suspend control from your current bot and move it to another bot, insert the name of the bot you would like to move to in the “Bot Name” field. In order to signal that the alternate bot has finished its job, it should have a botMissionDone node at the end of its flow. It will return to your initial bot once this node is reached.
To transfer to another bot (and not return to the initial bot) when an intent is triggered, simply select “transfer” as your BotNet action and insert the name of the bot you would like to transfer to in the “Bot Name” field.
Used to indicate this bot cannot handle this intent. Useful in situations where a bot might be greedy in similar or overlapping conversational topics
When using Push Bot To Stack, Transferring or Bot Mission Done, it is possible to enable message forwarding for some botnet actions. When message forwarding is enabled it will pass the last typed user message through to the next bot. It is also possible to override the message being forwarded to the bot instead of sending the last typed user message. Message forwarding is available for the following botnet actions:
The message forwarding configuration keys are as follows:
forwardMessage
- Can be true or false, specifies if a message should be forwarded to the next bot. If set to true the message will be forwarded, if set to false the message will not be forwarded.forwardMessageOverride
- The message that should be forwarded to the next bot, instead of the user typed message.The configuration for forwarding the last typed user message to the next bot for a botnet action looks like the following.
{
"type": "transferToBot",
"value": "bot-to-transfer-to",
"forwardMessage": true
}
The configuration for overriding the message being forwarded to the next bot looks like the following
{
"type": "transferToBot",
"value": "bot-to-transfer-to",
"forwardMessage": true,
"forwardMessageOverride": "this message will be sent to the transferred bot"
}
If forwardMessage
is set to false
or is not present in the action, no message will be forwarded to the next bot regardless of if forwardMessageOverride
is set. To forward a message forwardMessage
must be set to true
Message forwarding can also be set when specifying botnet actions within portal, below is an example of enabling message forwarding and overriding the message being forwarded
To pass in information when an intent is triggered, add a fulfillment action, select “Set Context” as your BotNet action, and enter the JSON containing the context you want to set. This context will then stay with the bot throughout the conversation.
You can also call on context using markup.
The setPolicy
Botnet Action is defined as:
{
"type": "setPolicy",
"value": {
"userSession": {
"expireOnInactivityInMinutes": 5
},
"conversation": {
"maxDurationInMinutes": 10
}
}
}
View the Conversational Policies documentation for more information.
### Preprocessing Preprocessing is supported on some botnet actions when using the nlp-worker. These actions are run before the targeted bot/worker handles the event.
Trigger intent is currently supported as a preprocessing event. You can configure it on the below actions
What it does is triggers that intent to fire as if we got an utterance that triggered that intent. You can configure it by adding the below to your intent definition. Please note this is not the full intent and is just a sub part of it
{
"fulfilment": {
"actions": [
{
"type": "botMissionDone",
"value": "EMPTY_STRING",
"preprocessing": [
{
"type": "TRIGGER_INTENT",
"configuration": {
"intentName": "welcome"
}
}
]
}
]
},
}