Omni Channel Actions Flow - Channel Routing
On this page |
Overview
This page explains how to configure and manage routing for the following channels: Email, Chat, SMS, Fax, Open Channel and WhatsApp.
Routing is controlled through a sequence of applications defined in the Channel Actions section. Each application performs a specific task for incoming interactions—such as notifying an agent, sending an auto-reply, or integrating with a bot like Amazon Lex, ChatGPT, or Dialogflow.
How it works
Each non-Voice channel (Email, SMS, Fax, Open Channel, WhatsApp) has its own Account section for routing setup.
Chat is an exception: it uses the Chat Websites section to configure snippets for website integration.
When editing an Account/Chat Website, you can select the Actions section
Actions can be configured to manage interactions coming through specific channel endpoints (e.g., Email Accounts, Chat Websites, etc.). These actions are defined in the Channel Applications list.
When a new interaction arrives on a channel, it follows the sequence of actions configured in this section.
Applications List for digital channels
Applications in the Action flow are executed in the order they appear in the list. The sequence and available applications may vary depending on the channel type.
Application | Channels | Description | Parameters | Other information |
|---|---|---|---|---|
Agent | Mail | Sends a notification to a specific Agent | - Agent name – Select the agent from the list. | - The selected agent is contacted, and routing is paused for the specified timeout duration. |
AmazonLex | Chat | It enables integration with an Amazon Lex bot. This application can be used as an Action within Chat and Open Channel routing flows.Note: using bots in XCALLY incurs additional costs for AI-managed conversations. These costs are visible in the AI Conversations dashboard starting from version 3.46.1. | - Access Key ID |
|
Auto Reply | Mail | Sends an automatic reply to incoming messages. | - Number of times per interaction: | First message starts even if customer does not write (chat request is considered as first message).Scenario |
ChatGPT | Chat | Supports action flow of an account to manage interactions with OpenAI modelsNote: using bots in XCALLY incurs additional costs for AI-managed conversations. These costs are visible in the AI Conversations dashboard starting from version 3.46.1. | - Choose OpenaAI cloud provider account | |
Close | Mail | Closes the interaction | - Disposition |
|
DialogflowV2(Starting from rel. 2.5.7) | Chat | Activates a conversational agent defined on Google DialogflowNote: using bots in XCALLY incurs additional costs for AI-managed conversations. These costs are visible in the AI Conversations dashboard starting from version 3.46.1. | - Project ID | See here for further documentation |
GoToIf | Mail | Jumps to an action in the flow according to the condition set | - Condition (variable or value) | Consider this information if you use GoToIf in your action plan. |
GotoP | Mail | Jumps to an action in the flow choosing the priority you want | - Priority (action in the list to execute) |
|
Noop | Mail | Writes information in a log file (for debugging purpose) | - Value |
|
Queue | Mail | Sends a notification to a specific Queue | - Queue (from list) | You associate agents to queue based on skills. When a new interaction arrives, it moves to queue depending on chosen strategy (Beepall all / RR Memory) |
System | Mail | Executes a unix command or script
| - Command (unix command or script to be executed) | System Application is very useful when you need to: |
Tag | Mail | Add a selected tag to the interactions | - Tag list |
|
When a new interaction arrives, the Action Flow begins.
Applications are executed in the order they are listed (e.g., Application 1 → Application 2 → Application 3, and so on).
The flow can dynamically jump between applications based on conditions defined in each application's configuration. This allows for flexible and intelligent routing logic.
Let’s walk through a sample Chat interaction flow:
Auto Reply: When a new chat arrives, an automatic welcome message is sent to the customer.
Custom Form (via Snippet)
A form is displayed, allowing the customer to choose their support type:1 – Chat with Sales
2 – Chat with Support
The selected value is stored in the variableSUPPORT_TYPE.
GoToIf – Check SUPPORT_TYPE
If
SUPPORT_TYPE = Sales→ Jump to Application 3Otherwise → Jump to Application 4
Queue (Sales): The chat enters the Sales queue with a timeout of 300 seconds.
If an agent answers within 300 seconds, the routing ends.
If no agent answers, the interaction proceeds to the next application.
GoToIf – Check SUPPORT_TYPE Again
If
SUPPORT_TYPE = Support→ Jump to Application 5Otherwise → Jump to Application 6
Queue (Support)
he chat enters the Support queue with a timeout of 300 seconds.If an agent answers, routing ends.
If no response, proceed to the next application.
Close Interaction: if the chat was not answered in either queue, the interaction is automatically closed using an unmanaged disposition, allowing tracking of unanswered requests.
Intervals
In the dialplan, each application is configured with a certain interval, that can be always, custom or list).
This means that when an interaction arrives, the system checks if the interval is respected and it follows the sequence of actions configured in the action section:
If interval is true, the application is executed
If the interval is false, the system passes to next application configured in the dialplan.
In the dialplan, empty intervals are not supported. A default interval must always be provided.
If you want that an application not to be performed, this interval must result as false.
Use Case
A business needs a specific playback to run in the dialplan only on certain, non-recurring days (e.g., a special discount event).
Because the interval field cannot be left empty, the system should be configured with a default interval that is guaranteed to be false (for example, February 31). When the playback must be enabled, replace the default interval with the actual, valid date for the event.
Interactions Priority
Each interaction is processed independently of the others.
If two interactions arrive at the same time—whether on different channels (e.g., a Chat and an SMS) or on the same channel (e.g., two Chats from different services)—their priority is determined by the routing flow configured for each interaction.
The order and behavior of the applications within the action flow dictate how and when each interaction is handled.
Each interaction always starts from the first application in the action flow. When an interaction is received, a new action flow is activated and processed independently.
Below are some common scenarios that illustrate how message handling works based on channel and flow configuration:
Scenario 1: two interactions on same channel
using the same actions flow
The interaction that arrives first is the one
that is handled first on the client side.
Scenario 2: two Interactions on the Same Channel Using Different Action Flows
Each interaction follows its own routing path.
The interaction that completes its action flow faster
will be presented first to the client or operator.
For example, if two chat interactions follow different flows,
the one that reaches the endpoint (e.g., agent queue or bot) faster will be handled first.
Scenario 3: two interactions on different channels
(1 chat and 1 mail)
A separate flow is created for each interaction based on the channel. The interaction that completes its routing flow more quickly is the one that is notified to the operator first.
For example, if the Facebook Messenger action flow contains more logic or conditions than the Chat flow, the Chat interaction may be handled first.