Sending Pause/Delay Message
It is possible to send a custom payload of type "delay" along regular content and actions. This specifies the time the bot will wait before sending the next message. The delay message can be added via the Custom Payload response in intent definition (as shown in Figure 3.2).
{
"delay": 8,
"typing": false
}
Figure 3.1 Example payload for a delay
- delay: This is the number of seconds the bot will wait. These are expected to be only whole numbers. E.g. for a one second delay you will write 1 as a value
- typing: This property will enable/disable the typing indicator while delay is happening. It is optional; if not provided then the value will be considered as true.
Figure 3.2 An example of Message — Delay — Message configuration in the Dialogflow console's intent editor
Note: Using the delay as a single/sole response from the bot to the consumer, is effectively a ‘no response’ action. Using this allows the bot to receive a consumer message without visibly responding to the consumer.
Sending Private Text Message
It is possible to send a private text message in the Conversational Cloud via agent workspace. This feature can now be used via the Third-Party bots as well. This will allow brands to define private message texts within the conversational flow of the bot. These messages are published into the conversation for other agent/manager participants. This enables brands to customize messages giving more insight, summarizing actions taken by the bot, or also advising on next actions the handover agent should take.
Please note If you have not migrated to new Agent Workspace you will not be able to see the Private
message indicator in the conversation window. Nevertheless, private text messages will not be shown to the consumer and only remain visible to Agents and Managers.
Please note private text message will never be shown to the consumer and will be visible only inside the conversation window of agent workspace. The private text message can be added via the Custom Payload response in intent definition (as shown in Figure 3.4).
It is possible to send only a private text message response. An example payload is seen below:
{
"messageAudience": "AGENTS_AND_MANAGERS",
"text": "This is a private message for agent from DialogFlow"
}
Figure 3.3 Example payload for a private text message
There are two properties, text
and messageAudience
, which are part of the Custom Payload response.
key | value | notes |
---|---|---|
text | any string value | mandatory |
messageAudience | value should be "AGENTS_AND_MANAGERS" | case-sensitive, mandatory |
Setting a private text message between multiple messages is also possible. Moreover, it is also possible to send a private text message with the combination of actions(e.g. Transfer / Escalations) as well. Example of such a case (Message — Private Text Message — Action) can be seen in Figure 9.1.
Figure 3.4 An example of transfer action with a simple text message and private text message in the Dialogflow console's intent editor
Message Context
Third-Party Bots provides additional message context to Dialogflow ES on the payload property. In order to access the payload in Dialogflow ES you need to configure a Fulfillment and ensure it is actived for the intent in question. Fulfillments can either be handled with Google Cloud Functions, or an external webhook can be configured. See Figure 3.5 for an example using Google Cloud Function.
Figure 3.5 Accessing the message context on a Fulfillment
LP Event
One of the provided payload properties is the lpEvent. A use case would be to access the metadata that has been send when the customer clicks a quick reply.
"use strict";
const functions = require("firebase-functions");
const { WebhookClient } = require("dialogflow-fulfillment");
const { Card, Suggestion } = require("dialogflow-fulfillment");
process.env.DEBUG = "dialogflow:debug"; // enables lib debugging statements
exports.dialogflowFirebaseFulfillment = functions.https.onRequest(
(request, response) => {
const agent = new WebhookClient({ request, response });
console.log(
"Dialogflow Request headers: " + JSON.stringify(request.headers)
);
console.log("Dialogflow Request body: " + JSON.stringify(request.body));
function metadata(agent) {
if (
request.original_detect_intent_request.payload.lpEvent &&
request.original_detect_intent_request.payload.lpEvent.metadata
) {
agent.add("We have received some metadata from you:");
agent.add(
JSON.stringify(
request.original_detect_intent_request.payload.lpEvent.metadata
)
);
} else {
agent.add("No metadata has been detected");
}
}
let intentMap = new Map();
intentMap.set("Button Action With Metadata", metadata);
agent.handleRequest(intentMap);
}
);
Figure 3.6 How to access the metadata of a customer message
Engagement attributes
Third-Party bots allows the collection of engagement attributes (more information can be found here) if Engagement Attributes
option is checked in the Conversation Type
step as shown in Figure 12.1.
Figure 3.7 Conversation Type step in creation/modification of bot configuration
These attributes are only collected at the start of a conversation.
Third-Party bots leverage the LivePerson Visit Information API to collect the engagement attributes.
Further information Visit Information API can be found here.
Moreover, Engagement attributes are not updated throughout the life cycle of a conversation and only passed along with each message request.
For DialogFlow ES, these engagement attributes are added to the property lpSdes
that is sub-property of the payload
(more information about payload
parameter can be found
here).
An example of the request body can be seen below:
{
"session": "SomeSession",
"queryParams": {
"payload": {
"lpEvent": {}, // Holds LP Events
"lpSdes": {}
}
}
}
Figure 3.8
Sending Encoded Metadata
Conversational Cloud Messaging platform provides a new metadata input type (“encodedMetadata”) for passing a base64 encoded metadata on a conversation. The new metadata input type is in addition to the existing conversation metadata input field. Third-party Bot also supports this property and this section will cover the information needed for you to send encoded metadata within your conversations. Before sending encoded metadata you must ensure the following conditions in order to successfully send the data.
- Common.EncodedMetadata AC feature is ON
- Content is base64 encoded
- Metadata size is limited to 5k
Failing to comply with the above validation points will cause the message to be dropped. This feature is only available for the messaging conversations not for chat conversations
Encoded Metadata can be sent with simple Text, Rich Content (structured content) and Multiple responses. For sending encoded metadata as a Text or Rich Content message you must use Custom Response
type for your relevant intent as shown in Figure 3.9 below.
Figure 3.9 Use custom payload for Encoded Metadata
Sending Text Message with Encoded Metadata
Please note that the default Text Response
option in Dialogflow ES will not work with encoded metadata feature.
You have to use Custom Response with the properties textResponse
and encodedMetadata
.
Be careful with the camel-case characters. You must provide it exactly the same.
- textResponse: This is the text that will be sent to the user.
- encodedMetadata: this is the property that will contain encoded metadata
{
"textResponse": "Hello I am a text response with encoded metadata!",
"encodedMetadata": "ewoic29tZUluZm8iOiAiSSB3YXMgZW5jb2RlZCIKfQ=="
}
Figure 3.10 Custom payload of text message with encoded metadata
Figure 3.11 Configuration in the Dialogflow ES Console
Sending Rich Content (structured content) with Encoded Metadata
You need to add another property of encodedMetadata
with your rich content object that you have created. An example of the simple Rich Content JSON
can be seen below:
{
"metadata": [
{
"id": "1234",
"type": "ExternalId"
}
],
"structuredContent": {
"type": "vertical",
"elements": [
{
"type": "button",
"click": {
"actions": [
{
"text": "Recommend me a movie, please",
"type": "publishText"
}
]
},
"title": "Recommend a movie"
}
]
},
"encodedMetadata": "ewoic29tZUluZm8iOiAiSSB3YXMgZW5jb2RlZCIKfQ=="
}
Figure 3.12 Custom payload for structured content with encoded metadata
Figure 3.13 Configuration in the Dialogflow ES Console
Invoke a LivePerson Function
During a conversation, it is possible to trigger a LivePerson Function that is deployed to the LivePerson Functions (Function as a Service) platform. This provides a way to run custom logic with a bot.
The method for triggering an invocation is similar to other
bot actions. Similar to a transfer action
Actions and Parameters
need to be configured in the Dialogflow console.
The action field needs to be set to INVOCATION to instruct the connector to invoke the specified LivePerson Function
It is also required to provide the lambdaUuid of the function that should be invoked in parameters. To retrieve the Lambda UUID of your LivePerson Function follow this guide
In addition, it is possible to send your own payload to the function. Set your content inside the payload key.
The bot does not escalate on a failed invocation by default. To enable this, set the additional parameter failOnError to true
Figure 3.14 Configure a LivePerson Function invocation
Receiving Rich Content Response (Messaging Only)
Third-Party Bots allows LivePerson's Rich Messaging channel capabilities not only to be received as a response from the vendor but also, allow Rich Messages (Structured Content) to be sent back to the vendor based on specific user interactions/responses (For example user sharing their location on WhatsApp). Please note these capabilities are sometimes limited by the channels in which the conversation is happening. For the list of Rich Messaging capabilities for each channel, browse or search the table on the Knowledge Center.
An example use case of the Rich Content event response sent by Third-Party Bots is described below. The example will show how to set up and access the RichContentEvent
response with Google Dialogflow ES after a user shares his/her location.
Create Intent for RichContentEvent
Customer needs to create a intent which should have training phase com.liveperson.bot-connectors.consumer.send-rich-content
as shown in the Figure 4.1 below.
Figure 4.1 Intent creation in Dialogflow ES console
Create Google Cloud Function
For accessing the RichContentEvent
body sent by Third-Party Bots you will need to create a Google cloud function that should be capable of receiving
the RichContentEvent
sent by Third-Party Bots. The minimal code example below shows how to check if there is a RichContentEvent
response present,
then send back raw RichContentEvent
data. Please note, that response sent by The Google Cloud function should follow the Dialogflow ES response schemas.
/**
* Responds to any HTTP request.
*
* @param {Request} request HTTP request context.
* @param {Response} response HTTP response context.
*/
exports.handleWebhook = (request, response) => {
let jsonResponse = {};
const {
originalDetectIntentRequest: {
payload: { lpEvent: { event = {} } = {} } = {},
} = {},
} = request.body;
if (event && event.type && event.type === "RichContentEvent") {
jsonResponse = {
fulfillment_messages: [
{
text: {
text: ["This is RichContentEvent"],
},
},
{
text: {
text: [`Raw event data: ${JSON.stringify(event)} `],
},
},
],
};
} else {
jsonResponse = {
fulfillment_messages: [
{
text: {
text: ["Unable to get any data for RichContentEvent"],
},
},
],
};
}
response.send(jsonResponse);
};
Example RichContentEvent
body of a map rich content that will be sent by Third-Party Bots on user sharing location in WhatsApp is as below:
{
"content": {
"type": "vertical",
"elements": [
{
"la": 49.82380908513249,
"type": "map",
"alt": "49.82380908513249, 2.021484375",
"lo": 2.021484375
}
]
},
"type": "RichContentEvent"
}
After adding cloud function make sure to deploy it and verify it is active.
Link Google/Third-Party Cloud Function to Fulfillment as Webhook
After the function has been deployed this needs to be added to the fulfillment section of the Bot Configuration. This fulfillment can be found in the Google Dialogflow ES console as shown in the Figure 4.2 highlighted area. Webhook need to be enabled and filled with the relevant information of the cloud function. (e.g. Auth Data and the Trigger URL)
Figure 4.2 Webhook configuration that need to be added for calling Cloud Function
Once Webhook configuration is added then the Google Dialogflow ES bot will be able to respond to the requests via the cloud function. A demo of our WhatsApp map example with Google Cloud Function (defined above) can be seen below:
Receiving Last consumer message (Messaging Only)
When an ongoing conversation gets transferred to a bot connected via the Third-Party Bot connector, the connector forwards the last consumer message to the AI vendor as part of the the welcome event. This allows the bot to react to the last consumer message instead of instantiating a new conversation.
We will describe an example of how to set up and access the WelcomeEvent response in Google Dialogflow ES below. We will use Google Dialogflow's capability of providing fulfillment via google cloud function as webhook.
Create Welcome Intent
Ensure you have an ‘entry point’ intent that utilizes the default ‘WELCOME’ event, if not you can create new intent triggered by the default WELCOME
event. After that enable webhook call for this intent in the fulfillment section, to be able to access the message context.
Figure 4.3 Configuration of the welcome event
Create Google Cloud Function
For accessing the WelcomeEvent body sent by Third-Party Bots you will need to create a Google cloud function that should be capable of parsing the additional message context sent by Third-Party Bots. The minimal code example below shows how to check if there is a lastConsumerMessage
and contentType
exists, then send back raw Event data containing the last consumer message. Please note, that response sent by The Google Cloud function should follow the Dialogflow ES response schemas.
/**
* Responds to any HTTP request.
*
* @param {Request} request HTTP request context.
* @param {Response} response HTTP response context.
*/
exports.handleWebhook = (request, response) => {
let jsonResponse = {};
const {
originalDetectIntentRequest: {
payload: { lpEvent: { contentType, lastConsumerMessage } } = {},
} = {},
} = request.body;
if (contentType === "welcome" && lastConsumerMessage) {
jsonResponse = {
fulfillment_messages: [
{
text: {
text: [`Last Consumer Message Received: ${lastConsumerMessage}`],
},
},
],
};
} else {
jsonResponse = {
fulfillment_messages: [
{
text: {
text: ["No Consumer Message found"],
},
},
],
};
}
response.send(jsonResponse);
};
After adding cloud function make sure to deploy it and verify it is active.
Link Google/Third-Party Cloud Function to Fulfillment as Webhook
After the function has been deployed, it needs to be added to the fulfillment section of the Bot Configuration. This fulfillment can be found in the Google Dialogflow ES console as shown in the Figure 4.4 highlighted area. Webhook needs to be enabled and filled with the relevant information of the cloud function. (e.g. Auth Data and the Trigger URL)
Figure 4.4 Webhook configuration that needs to be added for calling Cloud Function
Once Webhook configuration is added then the Google Dialogflow ES bot will be able to respond to the requests via the cloud function.
Send Secure Forms (PCI)
Secure forms are configured by LivePerson. To enable this feature, please contact LivePerson customer support or your account team. Your LivePerson account team will work with you make the necessary adjustments to your account settings and configurations. For additional information regarding secure forms: Knowledge Center
To give agents the permission to read secure forms sent by a bot, please contact LivePerson customer support to enable the site setting: messaging.display.secure.form.sent.by.bots
Bots are able to send a secure form to a conversation and transfer the customer after submission. The transferred conversation is then visible by an eligible agent, that can read and process the submitted form data.
To enable this feature in DialogflowES, you need to create a new Intent with a matching utterance and response to it. The response needs to send a SEND_SECURE_FORM
action including the unique formId
of the form, that should be provided from LivePerson after the creation of one secure form, and the title
of the form.
To transfer the conversation after submission to an eligible user that can process the secure forms, you need to create a new intent listening on the utterance FORM-SUBMISSION-INTENT
that transfers the conversation using a basic transfer event.