Conversation Embedded Apps
Embedding Apps
Embedded App example
Applications (aka Apps) displayed in the conversation flow are a very useful tool. They allow to achieve two main objectives:
Enhancement of the UI
Enhancement of the UI is obvious. You can, for example, play an entire video game in the conversation flow, without ever leaving the conversation in the chat. You can also complete a complex input form, that through a chatbot is difficult to fill. There are many use cases where an app running in the conversation increases the end-user perceived interactive power.
Data isolation
Data isolation is less obvious but probably more important. In Tiledesk, the conversational app is an entire web application running on its own web server on the HTTPS protocol. This means that data exchanged with the app is unknown by Tiledesk and is exchanged directly between the app and its own backend. This pertains to privacy and security.
Example: imagine a user should pay for a cart. The chatbot can provide to the user a payment-app where the user is asked about their credit card and these data are directly exchanged with the payment backend, never with Tiledesk. No info about the transaction is stored into the conversation. Through an app only the actors interested in the interaction are involved.
Conversation-embedded app anatomy
An App is just a message of type frame. See the Widget JSON protocol to see the details.
'frame' type message
Embed App with microlanguage
In addition to using the widget JSON protocol, you can use the microlanguage to render the App in the chatbot's reply without dealing with JSON specifications.
Copy
For example:
App height
You can also specify the App height in the conversation, using the following format:
For example:
With Tiledesk, displaying an app to the end-user means to simply send them a message.
App status
An app is totally under your control. You are responsible for the app data, app features, app usage of Tiledesk and third-party APIs, and the app status.
The "app status" is the status of your app in the conversation workflow. For example, an embedded payment app should be "active" only when the user has to pay, and "inactive" once the user stopped or terminated the payment.
To manage the app status there is a simple way: use the messageId that comes in the webhook of your application to uniquely identify your application. In the most frequent use case there is a strict correspondence between the App and the message where it is displayed.
Use the messageId as the App's unique reference on your backend. You can use this unique messageId as a unique-id in your database to save data relative to that app instance, including its status.
App > Tiledesk APIs interaction
Your App can always use Tiledesk APIs to communicate with your project, for example to send messages back to the conversation whenever it wants.
With each webhook payload you receive a token that you can use to talk with the conversation where the App is hosted. Use this token in Tiledesk APIs to call any allowed REST method you need.
Send messages to end-users
You can use API methods such as SendSupportMessage() to send messages to the conversation where the token belongs.
Sending messages from the App back to the conversation can be useful to notify the end of an operation and provide useful data.
It's now time to follow a Tutorial example: the Credit Card payment App tutorial.
Related: