Message types

Text messages are just that: messages containing text.

Depending on the value of the configuration property com.unblu.conversation.message.chatMessageAsMarkdownEnabled, the text may also contain Markdown.

For more information, refer to the description of the TextPostMessageData type in the Unblu web API reference.

Card messages group related information in a single container, a card. A card may contain the following elements:

A card message must contain at least one of these four elements. Each element on the card is independent of the others.

The sections below describe the properties of the various card elements. For more information, refer to the description of the CardPostMessageData type in the Unblu web API reference.

List messages consist of a header, a list of at most ten list items, and actions. In the example below, the header has a green frame, the list items have an orange frame, and the action has a yellow frame.

Each element is described below. For more information, refer to the description of the ListPostMessageData type in the Unblu web API reference.

File messages are used to send files. You can include an optional caption, text explaining what the file contains or asking the recipient a question. The caption can contain Markdown provided the feature is enabled. As with other message types, you can also provide a fallback text for use in notifications and previews.

Strictly speaking, quick replies aren’t a separate message type. They provide visitors with a range of possible responses to a message. However, unlike multiple-choice questions, the list of possible responses isn’t exhaustive.

Quick replies are displayed immediately above the standard text input field at the bottom of the Floating Visitor UI. The label of a quick reply may not be more than 40 characters long. If the length of the labels permit, quick replies are displayed next to one another:

If there are more than five quick replies, they’re always stacked. Initially, at most five quick replies are displayed.

In the example above, there are eight quick replies. The button in the lower right-hand corner of the conversation thread shows how many quick replies are hidden. It’s also used to display the three hidden quick replies:

You can add up to 13 quick replies to a question. However, we recommend providing between three and five quick replies.

Unlike multiple-choice questions, quick replies aren’t an exhaustive list of answers to a question. They’re merely suggestions. If the answer a visitor wants to give isn’t listed, they can enter it themselves in the chat text input field.

Quick replies are no longer visible under the following circumstances:

The configuration properties to customize the appearance of quick replies are grouped under the Quick reply UI heading in the Account Configuration interface.

Recording available messages give authorized participants the possibility to download a recording of the conversation. This only makes sense when conversation recording is enabled.

For more information about conversation recordings, refer to Conversation recording.

Multiple-choice questions offer visitors a fixed set of possible answers to a question. The visitor must choose one of the options offered for the conversation to proceed.

As the image above shows, you can specify whether possible answers should be displayed as primary or secondary buttons. The width of each button automatically adapts to the label it sports, although you can specify a minimum width using com.unblu.conversation.messaging.ui.multiChoiceButtonMinWidth. If a button’s label is longer than the space available on a single line, the label is truncated with an ellipsis.

If there are more than six possible choices, only the first five answers are displayed. The remaining choices are relegated to an overflow menu. You can change the maximum number of choices displayed with com.unblu.conversation.messaging.ui.multiChoiceMaxVisibleButtons.

For more information, refer to the description of the MultichoiceQuestionPostMessageData type in the Unblu web API reference.

Text questions require participants to enter a response to a question. The response must be entered in a separate field provided for this purpose. The usual text input field is blocked.

You can also specify a minimum and maximum length for the response, a regular expression that it must match, and the possibility to decline to give an answer to the question.

For more information, refer to the description of the TextQuestionPostMessageData type in the Unblu web API reference.

Rating questions require participants to select a value on a scale.

You can also specify whether it’s possible to skip rating the conversation.

For more information, refer to the description of the RatingQuestionPostMessageData type in the Unblu web API reference.

While this information can be useful, system messages can also be distracting. There may be too many of them, or the information they provide may not be relevant to all participants. You may therefore want to restrict the system messages shown to different participants. There are three groups of configuration properties that allow you to do so:

In each case, you specify the conversation participants who should receive the system messages in that category.

For a complete list of the configuration properties available, refer to the Conversation messages section of the configuration properties reference.

To see how the three groups differ, let’s consider some examples.

Many configuration properties for system messages include GHOST participants by default. This is to ensure that conversation logs provide a complete account of conversations, above and beyond the messages exchanged between the participants. However, this means that the conversation logs often include different system messages from the ones participants saw as the conversation unfolded.

In those cases where there are separate configuration properties for general and for direct system messages, the GHOST participant should be included in both configuration properties. This is because when you review conversation logs, you do so as a ghost participant. As a result, who a ghost is depends on who is reviewing the logs, which in turn affects which messages are displayed in the conversation logs.

Suppose, as in example 2 above, that your support agents launch embedded co-browsing sessions by providing visitors with a PIN. You have included the following configuration in the Join embedded co-browsing conversation template:

Imagine your support agent invites another agent to join the conversation, and it is the secondary agent who stopped the collaboration layer. When the assigned agent reviews the conversation logs, they see that the secondary agent stopped the co-browsing session. However, when the secondary agent looks at the logs of the same conversation, they don’t see a system message telling them who stopped the co-browsing session. This is because the secondary agent stopped the session, but the GHOST doesn’t receive system messages related to the person who initiated a change in the layer life cycle.