Integrations

Use integration elements in Flow to connect to external platforms.

Start a Conversation

This element is helpful if you want to direct customers to live agents or for similar scenarios. In the side panel, select a tag (create it on the spot or use the existing one) that tells the agent what the conversation will be about. For example, a data verification tag would mean that the agent will need to verify the customer`s information.

Start chatbot (Answers)

Use the Start chatbot (Answers) element to direct the end user from the flow to an Answers chatbot. After the chatbot session ends, the end user returns to the flow.

Prerequisites

• Answers enabled in your Infobip account. Only then, you can access the Start chatbot (Answers) element in your flow.

• An active Answers chatbot that uses a text-based channel such as SMS, Viber, or WhatsApp. To create a chatbot, refer to the Answers documentation.

  The Answers chatbot must use the same channel and sender that is used in the flow.

Criteria to design the flow

• The chatbot session can start only after it receives an initial message from the end user. Use the Evaluate inbound message element to obtain the end user's message.
• You can add the Start chatbot (Answers) element only after an Evaluate inbound message element. So, these 2 elements must be in the same branch in the flow.
• Transfer to agent must be done in the flow. If the chatbot contains the To agent element and the end user reaches this element, the end user returns to the flow. Use the Start a conversation element in the flow to connect the end user to an agent.

Process overview

1. The end user's message from the Evaluate inbound message element is sent to the Start chatbot (Answers) element through the LastInboundMessage variable.
2. When the end user reaches the Start chatbot (Answers) element, the flow automatically selects a chatbot that uses the same channel and sender that are configured in the Evaluate inbound message element.
3. The chatbot receives the message from the Start chatbot (Answers) element.
4. The chatbot session starts and the end user is redirected to the chatbot.
5. When the chatbot session ends, the end user returns to the flow.
6. The end user continues the journey based on the flow configuration.

Create the flow

1. Add an Evaluate inbound message element to the flow.

2. Configure the sender and condition in the element.

3. Add the Start chatbot (Answers) element to the same branch.

4. Configure the following fields in the element.

   • Chatbot sender: This field is prepopulated with the sender from the To recipient field in the Evaluate inbound message element.

     If you update the sender in the Evaluate inbound message element, you must update the sender in the Start chatbot (Answers) element. To do so, select Update chatbot sender.

     

   • Message received by chatbot: This field contains the LastInboundMessage variable by default. Specify any additional information and context that you want to share with the chatbot.

     The content of this field is sent to the chatbot.

   • Condition (Optional): Select one or more exit conditions to redirect the flow based on what happens in the chatbot session. In the Start chatbot (Answers) element, an exit branch is automatically added for each condition that you select.

     

5. For each exit branch in the Start chatbot (Answers) element, configure the next steps.

The following table contains descriptions of each condition and examples of the next steps for the condition.

Condition	Description	Example of next steps
Session not started	The chatbot session could not start. This could be for several reasons. Example: The chatbot was deactivated after the flow was activated.
Session ended externally (new session started)	The chatbot session ended because a new external session was started. Example: A new session was initiated for the end user through Conversations.
Session expired by timeout	The chatbot session timed out because the chatbot did not receive a response from the end user.	Retarget the end user the following day to check if their request was resolved successfully.
Closed by Close session element	The chatbot session was ended by the Close session element in the chatbot.
Chatbot deactivated	The chatbot was deactivated when the end user was in a chatbot session.
Redirect to agent failed	The chatbot was unable to transfer the conversation to an agent.	Add the Start a Conversation element to this branch to redirect the end user to an agent.
Session ended by user	The end user ended the chatbot session.

Analytics

To view the analytics for the Start chatbot (Answers) element, hover over the element in the flow.

Add to Flow

The Add to Flow element should be used when you would like to send your user to a different 'secondary' flow. This is a very powerful element that contributes to the creation of modular flows which can help you split very complex flows into smaller, more manageable flows.  To learn more, we've captured all the benefits of modular flows, when to use them, and also provided some examples in the Benefits of Modular Flows section of docs.

The Add to Flow element can be used at any position in a flow. If you use the Add to Flow element just before the exit element the user will end the current flow and be moved to another flow that you define. Whereas if you add the element at another step in the flow (that isn't the last step) then the user will continue the journey in both flows.

Variables and variable values can also be passed from your flow to a chosen flow using the Add to Flow element. By doing so you can ensure that as a user passes between flows any corresponding placeholder data will be passed too.

As good practice it is advisable to also include a failover branch at 'In all other cases' in the Add to Flow element. This way if it is not possible for the user to be transferred to the secondary flow (for instance, if the secondary flow is set to draft or has been canceled) then the user will still be able to continue on their journey.

Secondary Flow Participants

By default, any person passing through the Add to Flow element will also enter the secondary flow. They will participate in both primary and secondary flows until they exit from the flow.

You can also configure the element to so that another user can pass through the flow based on their contact information. To do so toggle to add another participant when you are adding your Add to Flow element. You can then define the primary contact information (phone number or email) to use for this participant that matches a flow variable, or a standard/custom attribute of the person who is currently in the Flow

If the participant exists in People then the flow will be started for the person as identified by their contact information and any mentioned attributes in the flow will be updated. If the person does not exist in People then a person profile will be created for them and an attribute value will be assigned to the profile.

A good use case for using the secondary flow participant functionality could be for a referral program to get the client to share the contact information of friends or family to receive benefits. As an example, you would ask the client  to share the email of a friend over messenger. Then you would parse the email from the inbound message and saving the value into a variable.

You can then use the Add to Flow element to start a flow for another person with contact information and email extracted from the variable. This is a great way to enhance your reach, just always ensure that there is opt-in confirmation from the friend or family member in order to meet data requirements for your region.

Call API

Call API will allow interaction between an external system, such as a website or a CRM, and Flow in real time. This is a step in the Flow builder which lets you to request information from your third-party system or database and save responses to flow variables to personalize and steer communication in the flow depending on that data.

In the side panel of this Flow element, you can set up the following: Request, Response, and Scheduling.

Request

The Call API request has the following parameters that should be set:

HTTP(S) URL – URL of the third-party system with which the flow wants to communicate. Be sure to specify the correct URL to the service that will receive or send the data that flow requires.

METHOD – defines the method that will be used to call API. These are POST, GET, PUT, and DELETE. Each of these is used for different use cases. Responses can be saved to variables (explained below):

POST– API that is called should do something with the provided request. Often POST is used to create a new entity or update an existing one on the third-party side.

GET– used to retrieve information from the called API.

PUT– used to store something on the third-party side.

DELETE– used to remove something on the third-party side.

PATCH– used to apply a partial modification to something.

HEADER – Data that will be sent along with the URL. Data can be entered in KEY-VALUE formats, such as username: user1 and password.

BODY – Data that will be sent along with the URL.  Data can be entered in KEY-VALUE format, such as name: Tom, or external user ID or in JSON format, for example {'name': 'Tom'}. Currently, two types of BODY are supported: JSON and URL Encoded Form. Default data entered by the user will be sent as JSON. To send it as URL Encoded Form data, you have to add a header with the name. Content-type and value: application/x-www-form-urlencoded

To authorize every call, you'll probably need to provide a username and a password in HEADER, and in BODY you should pass the EXTERNAL ID for each user stored in the People module so a third-party system knows which end user's data should be stored or fetched.

Headers are empty by default. Most of the web frameworks and services require a content-type header in the request to process it properly. For example, if you are trying to send a JSON, you should add a header with the name. Content type and value: application/json

Response

These are the parameters that need to be set for the Response:

WAIT UNTIL RESPONSE IS RECEIVED – select this check box and the next step in the Flow will be activated only after the response has been received.

RESPONSE HEADER VARIABLE -  allows the server to pass additional information about the response which cannot be placed in the Status-Line. The header fields provide information about the server and further access to the resource identified by the Request-URI.

RESPONSE BODY VARIABLE – the called API data received from the external system can be saved to a flow variable and used in the rest of the flow. To save data to the variables you will need to do the following: Enter a JSON path expression such as $ loyalty_points. A path must point to a single value; if the value is an array or object, it will be considered an error and NULL will be set to this variable.

Handle Error Codes

The flow can be branched based on whether the response has been received or not, and based on the error code.  Use Conditions to specify how you want to treat the response codes.

The code types:

On success - *Exit: “In case of 2XX error”.*Requires no action and it is being handled through the prior conditions.
On error - Exit: "In case of any error."
All client error codes - Exit: "In case of 4XX error."
Server error codes - Exit: “In case of 5XX error.”

Scheduling

The options shown in this section will help streamline the data exchange. To start scheduling, enable the following features in the Scheduling tab:

Delivery Time window

•    Select the start time for data delivery
•    Select end time for data delivery
•    Select the time zone

Define Message Sending Speed

•    Enter the number of messages you want delivered within a specific time period
•    Select per minute, per hour, or per day

Custom Exchange elements

Create custom elements in Exchange and use them in your flow to add new functionality to the flow.

Example: Create a custom element to integrate your flow with third-party systems. Call third-party APIs and personalize the flow journey based on the response.

Configure the element once and reuse it across multiple communications.

The following are examples of use cases.

• Integrate your flow with a webinar platform to automatically register the end user for meetings.
• Connect your flow with a GenAI platform to generate personalized content within the flow.
• Connect your flow to your CRM to transfer data or add profiles to specific groups.

For more information, refer to the Developing with Infobip documentation.