Your customer data is often spread across various online systems, whether they are custom or 3rd party. No matter where your customer data is, you can now use it for conversational routing of calls and emails in Dixa.

There are many reasons why you would want to route with external data, here's some examples on how certain industries would benefit from this:


  • If the total order of the customer calling in is larger or smaller than a given size, then route this conversation to a specific queue/agent.
  • If the Customer Lifetime Value (CLTV) of the customer calling in is larger or smaller than a given size, then route this conversation to the specific queue/agent.
  • Have the customer enter the order number and route them to the relevant queue/agent based on this.


  • If the customer calling in has a Lead Status of a given type, then route the conversation to the specific queue/agent.


  • If the customer calling in has a Net Promoter Score (NPS) higher or lower than a given value, then route this conversation to a specific queue/agent.

Setup for call and email flows

When editing Telephony and Email flows, an option to integrate data from an external system e.g. a CRM is available through the Integration block:

Configuring the Integration block

The integration block allows you to connect to an external system's API, so you can query relevant data from that system.

HTTP method

The Integration block represents a full-blown HTTP client and every known HTTP method defined in the REST protocol can be utilized. So in order to access a specific property in your external system, you could for example, use the GET method.


The endpoint which the Integration block should point to can be either a custom (non-commercial) API as well as a known commercial API's e.g. other relevant CRM systems with customer data. 

The example below is an endpoint from Hubspot's Contact API, retrieving a Hubspot contact by a unique email address:   

Create/Update external data

Some use cases would involve creating or updating data in an external system. Often the HTTP methods for this purpose are any of the following:

  • POST
  • PUT

Which HTTP-method to use for any type of operation is dictated by the API you wish to integrate to. A body of content for the request is expected in any case though and this information can typically be found in the API documentation of the external system you wish to integrate with.

Test HTTP request

In order to validate if an endpoint has been configured correctly, an opportunity to test the HTTP request is available in the 'Test'-tab.

Performing the HTTP test request also allows you to see which information and properties the chosen endpoint returns. Looking at the response from the API, it is then also easy to copy the properties you are interested in from the payload. Knowing the correct format of the properties is important because you will need to specify those as variables, so they can be used afterwards in your flow as a Flow Variables (see definition further down):


Depending on the specific API that you want to integrate with, several options are available regarding authentication. 

In the example used throughout this article, an API-token from Hubspot has been used directly in the request.

It's possible to define and send through header-information (key-value pairs), as well as to generate Basic auth from the Integration block:


System Variables & Flow Variables

Notice the purple placeholder 'From email' above, which is a dynamic variable representing the email address of any incoming customer contacting you via email.

There are two notions of dynamic variables:

  • System Variables
  • Flow Variables

System Variables are variables already defined based on the triggered channel initiating the conversation. If the triggered channel is Email the available system variables will be:

  • From email
  • To email
  • From name
  • Subject
  • Body
  • CC emails (comma separated)

On Telephony triggered flows, these a limited to:

  • Caller number
  • Receiving number

Flow Variables are variables defined on-the-fly by the returned data from an HTTP Response of the integrated API. These Flow Variables you will need to label and map to the right JSON-path from the returned payload:

In the above example the Lifecycle Stage as well as the Hubspot Owner ID is imported and stored as temporary Flow Variables to be used further down in the flow.

Handling latency

Depending on the context (what kind of Conversational flow / Channel) is currently being created or updated, the Integration block displays minor differences, due to the nature of the specific channel.

As seen above, the Integration block in a Telephony flow, has an 'announcement section'. This is due to the nature of a call being a real-time activity, where latency would result in a bad experience for the end-user. 

When an endpoint has been configured, the length of the announcement defines the accepted wait-time for the external API to respond. If the API doesn't respond within the announcement timeframe, the flow will continue, but no external data will have been integrated into the scope of the flow for further execution.

Integration options

The Integration block is a powerful component within the scope of conversational routing, and the possibilities are many. 

There are two larger options regarding integration options:

  • Custom API's (Often self-developed and hosted API's)
  • Commercial API's (E.g. Hubspot, Shopify, Salesforce, etc.)

In order to integrate with either one of these two options, the important aspect is whether they offer an endpoint in which a dynamic variable (unique value) from Dixa can return the relevant record (often a specific customer data record), based on the passed along unique variable.

Even though the Integration block supports responses of both objects as well as arrays, it is considered best practice to get a single record returned per Integration block configured.