Contact usRequest a demo

Conversation and participation life cycles

Each conversation goes through a number of different states which determine what can or must occur within the conversation for it to proceed. The state of a user’s participation in a conversation goes through a similar (but not identical) series of changes. These series of transitions from one state to the next are referred to as the conversation life cycle and participation life cycle, respectively.

The conversation life cycle

The conversation life cycle is a simple series of transitions from one state to the next. It’s influenced by the participation states of the users taking part in the conversation as well as the engagement type of the conversation. The latter determines which conversation template is used when creating the conversation. This in turn determines which transitions are possible (or necessary) in the conversation’s life cycle. The following diagram shows all the possible conversation states and the order of transition.

conversation life cycle
Figure 1. The conversation life cycle

A conversation needn’t necessarily go through all the states in the diagram above. If a visitor declines the Terms and Conditions, for example, the conversation state changes from ONBOARDING to ENDED. Some states, such as UNASSIGNED, are only used in certain configurations.

Conversation states

The conversation states specify the overall state of a conversation.

Created

This is the initial state of a conversation, regardless of whether it was a visitor or an agent who started the conversation. Whoever started the conversation automatically joins the conversation as the context person (visitor) or assigned agent, respectively.

Onboarding

While the central person of the conversation is completing the onboarding process, the conversation is in the ONBOARDING state.

During the onboarding process, the participant can only see dialog messages exchanged with the bot or bots involved in the onboarding process. Once they have completed the process, they will see any messages sent to the conversation in the meantime.

The central person of a conversation need not be the person who initiated the conversation; see Engagement types for more details.

If the onboarding process you put in place doesn’t require any action by the visitor, Unblu can complete the onboarding process without waiting for the visitor to open the conversation. This is the case if, for example, you aren’t using the concierge or any other dialog bots, or if the concierge merely displays a message.

If you use an external dialog bot, Unblu doesn’t know whether the visitor has to answer any questions, so it always waits for the visitor to open the conversation.

Unblu completing the onboarding process without waiting for the visitor to open the conversation is referred to as fast onboarding. Fast onboarding isn’t a way of speeding up the onboarding process.

Queued

If the conversation was initiated by a visitor, the conversation’s state will change from ONBOARDING to QUEUED once the central person has completed the onboarding process. A conversation may also be assigned this state by calling the web API endpoint /invitations/requeueConversation on it to move it to the queue.

The conversation remains in this state until an agent joins the conversation.

Active

A conversation is ACTIVE once two primary participants have joined the conversation (if the conversation was initiated by a visitor) or once the central person has completed onboarding (if the conversation was initiated by an agent).

Unassigned

When the assigned agent leaves an ACTIVE conversation, the state of the conversation changes to UNASSIGNED. If the visitor remaining in the conversation as a participant wishes to resume the conversation, they can simply send a message to start the reboarding process.

Whether a visitor can stay in a conversation after the assigned agent has left depends on how the conversation or its template is configured. Only conversations originally initiated by visitors can be UNASSIGNED. All other conversations end when the assigned agent leaves.

For more information, refer to Engagement types.
Reboarding

When a message is sent to a conversation whose state is UNASSIGNED, the conversation’s state is set to REBOARDING until the central person has completed the reboarding process.

During the reboarding process, the participant can see:

  • Messages that were sent to the conversation before the reboarding process started

  • Dialog messages exchanged with the bot or bots involved in the reboarding process

  • Dialog messages from earlier onboarding or reboarding processes

Once the reboarding process is completed, the conversation is placed in the queue again for an agent to accept. The participant also sees any messages sent to the conversation during their reboarding. If the process is canceled, the conversation state reverts to UNASSIGNED.

Offboarding

When an active conversation is ended, its state changes to OFFBOARDING. The conversation remains in this state while the participants complete their respective conversation offboarding processes.

During the offboarding process, participants can see:

  • Messages that were sent to the conversation before the offboarding process started

  • Dialog messages exchanged with the bot or bots involved in the offboarding process

  • Dialog messages from earlier onboarding or reboarding processes

Ended

When the offboarding process has been completed for each participant, either by the participants themselves or due to timing out, the conversation’s state changes to ENDED. Participants that didn’t leave the conversation remain active participants of the conversation. This lets them view the details of the ended conversation later.

Starting a conversation

When a visitor wants to start a conversation, they generally either click a button in the visitor UI or trigger the execution of code you wrote that uses one of the Unblu JS APIs. You might also want to start a conversation from within your organization’s CRM by calling the Unblu web API.

In both cases, Unblu tries to start a conversation with a certain engagement type. For example, you may have added a link to your organization’s e-banking that lets users request an embedded co-browsing session with a support agent. When a user clicks the link, you call UnbluAPI.startConversation() with the type DOMCAP_BROWSER_REQUEST.

The configuration property com.unblu.messenger.startWithOfflineChatOptionEnabled gives you the possibility to let visitors start a conversation even though there are no agents available to deal with their request. This engagement type is called an xref../../knowledge-base/reference/conversation-elements.adoc#offline-chat-request-offline_chat_request[offline chat request]. All other engagement types are online requests.

The evaluation procedures for online and offline requests differ.

In the case of offline chat requests, the visitor’s client sends the offline chat request to the Unblu server. The server then carries out the following checks:

  1. Is there an agent available to deal with the request?

If you’re using version 3 of the Unblu mobile SDK with Unblu 7 and you want visitors to be able to start conversations even though no agents are available, set the configuration property com.unblu.messenger.ignoreAgentAvailabilityForOnlineRequest to true.

For online requests, the evaluation procedure looks like this:

  1. The visitor’s client checks whether an agent is available to handle the request.

    • If an agent is available, the client sends the chat request to the Unblu server.

    • If no agent is available, the client throws an error and displays a message explaining the situation.

  2. Upon receiving a chat request, the Unblu server also checks whether an agent is available.

    • If there is an agent available, the server adds the request to the queue.

    • If no agent is available, it raises an exception and returns it to the visitor’s client.

If you create conversation requests from the visitor side, you should always check that an agent is available before you transmit your conversation request. If no agent is available, only send requests with the conversation type OFFLINE_CHAT_REQUEST.

For more information on setting agent availability at the account level, refer to Setting queue availability manually.

Leaving vs ending a conversation

When a participant leaves a conversation, they no longer have access to the conversation: they can’t view it in their conversation history, nor can they rejoin it. If they wish to rejoin the conversation, they will need a new invitation. However, the conversation hasn’t necessarily ended.

When a conversation has ended, on the other hand, participants who didn’t leave the conversation remain active participants in the conversation and continue to have access to it in their conversation history. Although an ended conversation has active participants, it isn’t possible to send new messages to an ended conversation or to invite people to join it. A conversation that has ended is in a state that can no longer change.

You can specify that a conversation should end when participants leave with the configuration property com.unblu.conversation.lifecycle.autoEndOnLeave. It’s also possible to configure Unblu so that participants automatically leave or end a conversation when they disconnect. The relevant configuration properties are

Closing a conversation

When a user closes a conversation, they navigate away from it, for example by closing the browser tab that the conversation was taking place in. Closing a conversation doesn’t affect the conversation state, but you can configure Unblu so that participants automatically leave or end a conversation when they disconnect.

If you want the UI to close automatically when a conversation has ended, you can set it to do so for different participants with the following configuration properties:

The setting doesn’t have an effect if it’s Unblu that ends the participation in a conversation, for example because they declined the terms and conditions during onboarding. In such cases, you can’t close the UI automatically.

The participation life cycle

The participation life cycle describes how the state of a user in relation to a conversation changes in the course of that conversation.

Participation states

Created

The participant has been created.

Onboarding

The participant is completing the onboarding process for the conversation. During the onboarding process, the participant can only see messages that are part of the onboarding process.

Active

The participant has joined the conversation and is an active member. If the participant doesn’t leave the conversation, their participation in the conversation will remain active even after the conversation has ended. For more information, refer to Leaving vs ending a conversation.

Offboarding

The participant is completing the offboarding process to leave the conversation.

A participant’s state only changes to OFFBOARDING if they leave the conversation. If they remain in a conversation until it ends, they will be required to complete the conversation offboarding process, but their participation state will remain ACTIVE.
Ended

The participant is no longer present in the conversation and no longer has access to it.