Virtual Agent Bot Interconnect functions as the primary bot in a diverse chat environment. It can help you reduce complexity and create a unified chat experience for your end users. Virtual Agent Bot Interconnect gives your end users access to multiple channels and a wide variety of enterprise tasks that are available from ServiceNow.

Supported Controls

All input controls and bot response controls are supported.

Features and default behavior

Language support

Responses in Bot Interconnect are not translated. Bot Interconnect passes the user language to the secondary bot and expects the secondary bot to return any responses in that language. For example, if the primary bot has a German-speaking user and the secondary instance is localized in German, then German responses are returned to the primary bot.

Timeout value from the secondary bot

The timeout value is the maximum time the primary bot waits for a response from the secondary bot. You can pass a custom timeout value (in milliseconds) in the Bot Interconnect Topic Block properties to override this.

1. Select the Bot Interconnect Topic Block node in the shell topic on your primary instance.
2. In the Additional Params (String) area, select the script icon .
3. Add the following script:

   return JSON.stringify({ timeout : 30000 })

   In this example, 30000 equals 30 seconds.
4. Save and publish the topic.

Closed conversations

Conversations are closed on the secondary bot when a user closes the conversation on Bot Interconnect or when the Bot Interconnect conversation times out.

Note:

Conversations always remain open in Microsoft Power Virtual Agents.

Debug logs

To enable debug logs in the Bot Interconnect instance, set the sn_va_bot_ic.bot_interconnect.enable.logging system property to true. You will see a conversation ID attached to most logs, as well as the file name.

Pass output from the secondary bot topic to the primary bot

You can apply custom logic to the output of the secondary bot conversation in the Bot Interconnect shell topic.

Support for custom transformation maps

Developers can pass a custom transformation map using the getTransformerMap method. A custom transformation map lets you override the default transformation logic.

Example in the DialogflowInboundTransformer script include for Google Dialogflow:

/** Custom transformation map based on control types in DialogFlow messenger **/

getTransformationMap: function() {
	return {
		‘text’: ‘transformText’,
		‘info’: ‘transformInfoCards2’,
		‘description’: ‘transformDescription’,
		‘button’: ‘transformButtonLink’,
		‘image’: ‘transformImage’,
		‘chips’: ‘transformChips’,

		/* fallback logic in case VA API response format is mentioned in Dialogflow custom response payload */
		‘servicenow’: ‘transformServiceNowResponse’
	};
},

In this example, text, info, description, and so forth are the control types that correspond to the secondary bot. The specified method (such as transformText) is called to do the transformation for the control type. For each secondary bot response, Virtual Agent uses the getControlType method to return the control type specified in the transformation map for the secondary bot message. The inbound transformer in Google Dialogflow provides a good example for how to use this.

If the transformation method called does not exist, Virtual Agent API logs it as an error.

Live agent connection

You can enable live agent connection to route a Virtual Agent interaction in the primary instance to a live agent on the secondary instance. The following are the possible connection scenarios.

• If there are no matching agents available in the primary instance to cater to the interaction, Bot Interconnect will evaluate the matching conditions configured in the live agent connection and route the interaction to the appropriate live agent in the secondary instance.
• If there is only one matching connection, the interaction is routed to that connection and agent availability is checked in the secondary instance.
• If there are multiple matching connections, the user is presented with options in the order defined and is connected to the selected connection.
• If there are no matching agents available in the secondary instance, the following message is displayed: "There are no agents available. Please try again later.".
• If there are matching agents available in the secondary instance, the user is redirected to the available live agent who can cater to the interaction.

Autopilot mode is currently not supported in the secondary instance when the conversation is initiated on the primary instance. Live agent connection in the secondary instance works only when the secondary instance is in asynchronous mode.