Start Node
The Start node is configured to trigger a flow using a channel, integration, webhook, or a custom event. This node allows you to configure the flow trigger in the context of the standard flow configuration. Further, the data from the trigger is available as node-level variables for use in the other flow nodes.
Start Node
While creating a new flow, you are prompted to configure the start node. You can choose either to configure or skip to do it later. Select a trigger and configure the details. Click the close icon at the upper right corner of the page to skip the trigger configuration.
Trigger Category
Triggering a Flow on various Channel Events
| Channel | Possible Events |
|---|---|
| SMS | Mobile Originated - MO (Allows you to trigger the flow on an incoming SMS message) On Link Click Refer 'Conditional Trigger in SMS' section if you want to use the 'Trigger only when there are no live sessions option'. |
| Voice | Inbound Call Missed Call Note: Webex Connect offers the ability to trigger the same flow for incoming calls received on more than one phone number by using a routing number option. The mapping of the routing number with the set of phone numbers for dialing is to be configured by the Ops team. Reach out to Ops team if you want to use this feature._ Currently, the routing number feature is supported in the USA and Canada only. |
| MMS | Mobile Originated - MO (Allows you to trigger the flow on an incoming MMS message) |
| Messenger | Incoming Message On Link Click Postback |
| Incoming Message - This event occurs every time a user sends a text message with or without attachments to your Instagram account. Postback - This event is triggered when user clicks postback type button. Message Deleted - This event occurs every time a user sends a delete message to your Instagram account. | |
| Incoming Message - details of the sender ID and name are displayed. The whatsapp.username output variable contains the sender's user name. Postback - Postback event captures the payload received when a customer clicks on a quick reply button within an interactive template List Message - This event occurs every time a user selects one of the List Message options Reply Buttons Message - This event occurs every time a user selects one of the Reply Buttons options | |
| Mobile & Web App | Custom Event Geo Enter Geo Leave Incoming Message - _inappmessaging.appid output variable captures the app ID corresponding to the incoming event On Thread Closed - this event can be used to trigger a workflow in cases where an agent has resolved a client query and marked the conversation as closed, or if a customer has abandoned a chat and the chat is marked as closed due to it being timed out. The reasonForThreadClosure captures the reason for closing the thread. OnPostback - this event is triggered when the user clicks postback type button Subscribe - this event is triggered when the user clicks re-subscribe button Unsubscribe - this event is triggered when the user clicks unsubscribe link |
| Incoming Message Subscribe Unsubscribe The platform will not trigger or resume a flow, nor trigger a rule or an outbound webhook notification for incoming emails where Sender Email ID is same as the Recipient Email ID. However, details of such incoming emails will be available within Export Logs. | |
| Apple Messages for Business | Conversation Closed Incoming Message Interactive Message: Classical Authentication Interactive Message: Form Response Interactive Message: iMessage App Response Interactive Message: List Picker Or Time Picker Interactive Message: New Authentication Interactive Message: Payment Interactive Message: Quick Replies (A flow is triggered when a Quick Reply message is received from a customer.) Typing Indicator |
| RCS | Incoming Attachment Incoming Message Location Response Postback |
Flow Triggers for Integrations
| Integration | Possible Events |
|---|---|
| CCSP | Agent Chat Initiated Chat Closed Chat Idle Chat Opened Chat Picked Chat Reopened Chat Transferred Custom Event Incoming Message |
| BOT (Deprecated) | Custom Event Handover Milestone Reached Notify Unhandled Message |
Triggering a Flow using Custom Event API or Inbound Webooks
| Custom Trigger | Possible Events |
|---|---|
| Webhook | Select an existing webhook Create a new webhook event |
| Custom event | Select an existing event Create a new event |
Trigger Conditions in Start Node
The platform allows selective triggering of the flow only when the conditions set on the trigger event are fully met. The list of variables on which a condition can be set is dependent on the trigger event. For example, conditions can be set on the inbound message or the sender number for an MMS trigger with an inbound message.
Different conditions on variables can be set using the AND/OR operators. When AND is part of the condition, that part of the condition must be true to qualify the condition. When OR is used, the statement is executed if any one of the conditions qualifies.
Inbound SMS with a condition on the text message set as trigger to invoke the flow
One of the several conditional operators that can be used to set conditions are listed below:
- Equals
- Not equals
- In
- Not in
- Contains
- Greater than
- Less than
- Greater than equal to
- Less than equal to
- Equals ignore-case
- Between
- Starts with
- Ends with.
Configure a Custom Event in Start Node
To configure a custom event:
- Create a flow.
- Select Custom Event as the trigger. Or, you can also double-click the Start node and select the trigger as Custom Event.
- Select an existing event or Create a new event based on your requirement. Enter a suitable name and configure the required variables. Provide a suitable name for the new event.
While configuring custom events within the Start Node:
- A pre-selected read-only checkbox is visible on the screen to highlight that it is mandatory to pass service authentication credentials when using Custom Event v1
Custom Event Configuration
- The sample payload is dynamically generated for API request body based on the configured parameters. The event id i.e.,
evtidfor the configured custom event is generated once you save the configuration.
Dynamically Generated Sample Payload
You can start using the custom events in the flows. When you use the custom event node in a flow, the event URL is auto-populated and authentication is mandated.
Conditional Trigger in SMS
Webex Connect allows you to conditionally trigger a flow on receiving an incoming SMS message only if the configured conditions are met. Here's how you can use this feature:
- Double-click the Start node and select 'SMS - Mobile Originated - MO' as the flow trigger.
- Provide the required details like SMS event, Incoming Number, and Keyword.
Conditional Trigger
When the Trigger only when there are no live sessions checkbox is enabled, the flow will be triggered only if no Receive node is waiting with a matching keyword and incoming number.
For example, let us suppose there are two flows Flow 1 and Flow 2:
Flow 1: The Start node in Flow 1 is selected as SMS and the keyword configured in the Start node is 'Help'. The next node is the Receive node with a (anything) keyword.
Flow 2: The Start node is Flow 2 is selected as SMS and the keyword configured in the Start node is (anything).
- If Flow 1 and Flow 2 are in the same service -
When there is an incoming message with the Help, Flow 1 is triggered. With the Help keyword, only the matching flow gets triggered (i.e., Flow 1). We have a Receive node in Flow 1, Flow 1 is waiting at the Receive node. Now, if the next message from the user is 'I need help with a laptop’ then- Scenario 1 - Checkbox is not enabled in Flow 2 and Flow 2 is in the same service as Flow 1.
The second message 'I need help with laptop' will trigger Flow 2 Start node and Flow 1 Receive node times out. - Scenario 2 - Checkbox is enabled in Flow 2 and Flow 2 is in the same service as Flow 1.
The second message 'I need help with a laptop' will resume only the Flow 1 Receive node.
- Scenario 1 - Checkbox is not enabled in Flow 2 and Flow 2 is in the same service as Flow 1.
- If Flow 1 and Flow 2 are in different services -
When there is an incoming message with the Help keyword, Flow 1 is triggered. We have a Receive node in Flow 1, Flow 1 is waiting at the Receive node. Now, if the next message from the user is 'I need help with a laptop’ then- Scenario 1 - Checkbox is not enabled in Flow 2 and Flow 2 (with keyword) is in a different service from Flow 1.
The second message 'I need help with laptop' will trigger the Flow 2 Start node and Flow 1 Receive node, and both get resumed. - Scenario 2 - Checkbox is enabled in Flow 2 and if Flow 2 is in a different service as Flow 1.
The second message 'I need help with a laptop' will resume only the Flow 1 Receive node.
- Scenario 1 - Checkbox is not enabled in Flow 2 and Flow 2 (with keyword) is in a different service from Flow 1.
Illustration
Let us look at an illustration to understand this clearly.
| Service 1 | Service 2 |
|---|---|
| Flow 1 - Start node configured with Help keyword followed by a Receive node with "*" as the keyword. | Flow 5 – Start node configured with "*" as the keyword followed by a Receive node with "*" as the keyword. You need to disable Flow 3 to enable this flow since Flow 5 is in a different service, you need to disable Flow 3. |
| Flow 2 - Start node configured with Help keyword followed by a Send SMS or any other node. | Flow 6 – Start node keyword configured with Balance keyword followed by a Receive node with "*" as keyword. |
| Flow 3 - Start node configured with "*" as the keyword followed by a Receive node with "*" as the keyword. | |
| Flow 4 - Start node configured with Loan keyword followed by a Receive node with "*" as keyword. |
The behavior of the flows is illustrated in the following table:
| Conditions (Trigger message and receive) | Checkbox status in different flows | Behavior |
|---|---|---|
| Message 1 – Help Message 2 - Loan | Enabled for Flow 1 Disabled for Flow 2 Enabled for Flow 3 Enabled for Flow 4 NA for Flow 5 Enabled/Disabled for Flow 6 | Message 1 triggers Flow 1 and Flow 2 Message 2 will be received by Flow 1 and Flow 2 receive node |
| Message 1 – Help Message 2 - Loan | Enabled for Flow 1 Disabled for Flow 2 Enabled for Flow 3 Disabled for Flow 4 NA for Flow 5 Enabled/Disabled for Flow 6 | Flow 1 and Flow 2 get triggered when Help is sent Message 2 triggers only Flow 4 and does not trigger Flow 3. |
| Message 1 – Total Message 2 - Loan | Enabled for Flow 1 Disabled for Flow 2 Disabled for Flow 3 Disabled for Flow 4 NA for Flow 5 Enabled/Disabled for Flow 6 | Message 1 triggers Flow 3 Message 2 triggers Flow 4 as the checkbox is disabled and will be received by Flow 3 Receive node |
| Message 1 – Total Message 2 - Loan | Enabled for Flow 1 Disabled for Flow 2 NA for Flow 3 Disabled for Flow 4 Enabled for Flow 5 Enabled/Disabled for Flow 6 | Message 1 triggers Flow 5 Message 2 triggers Flow 4 as the checkbox is disabled and will be received by Flow 5 Receive node |
| Message 1 – Total Message 2 - Balance | Enabled for Flow 1 Disabled for Flow 2 NA for Flow 3 Disabled for Flow 4 Enabled for Flow 5 Disabled for Flow 6 | Message 1 triggers Flow 5 Message 2 triggers Flow 6 as the checkbox is disabled and will be received by Flow 5 Receive node |
| Message 1 – Balance Message 2 - Loan | Enabled for Flow 1 Disabled for Flow 2 Disabled for Flow 3 Disabled for Flow 4 NA for Flow 5 Disabled for Flow 6 | Message 1 triggers Flow 6 Message 2 triggers Flow 3 and will be received by Flow 6 Receive node |
Output Variables
Please refer to Output Variables in Receive Node page to understand the details of Output Variables available for various channel events.
Flow Trigger Behaviour in Digital Channels
Note
This section is applicable to all the digital channels: WhatsApp, RCS, Messenger, Apple Messages for Business, Email, and Mobile and Web.
As an example WhatsApp is shown in the images.
Webex Connect allows you to trigger a flow on receiving an incoming message only if the configured conditions are met. Here is how you can use this feature:
Illustration
Let us look at an illustration to understand this clearly.
Scenario 1 - within Same Service
| Service 1 |
|---|
| Flow 1 - Start node event type (Postback for channel). Receive node waiting on ‘Incoming Message’ as event type. |
| Flow 2 - Start node event type (Incoming message for channel). Receive node waiting on ‘Incoming Message’ as event type. |
| Flow 3 - Start node event type (Inbound Webhook for channel). Receive node waiting on ‘Incoming Message’ as event type for channel. |
The behavior of the flows is illustrated in the following table:
| User’s Messaging Behavior | Scenario breakdown | Behavior |
|---|---|---|
| User sends a Postback message followed by two Incoming messages, one after the other. | User sends a Postback message. | Flow 1 with Postback event gets triggered and the receive node is waiting. Flow 2 is not triggered. Flow 3 is not triggered. |
| User sends a Incoming message. | Flow 1 is not triggered and the receive node is waiting. Flow 2 is triggered and the receive node is waiting. Flow 3 is not triggered. | |
| User sends another Incoming message. | Flow 1 is not triggered. Flow 2 is continued and ended successfully. Flow 3 is not triggered. | |
| After maximum time-out. | Flow 1 is completed with onTimeout and is shown as End-Incomplete. | |
| User sends three Incoming messages one-by-one. | User sends first Incoming message. | Flow 2 is triggered and the receive node is waiting. Flow 1 and Flow 3 are not triggered. |
| User sends second Incoming message. | After second Incoming Message is sent, Flow 2 is continued and completed successfully. Flow 1 and Flow 3 are not triggered. | |
| User sends third Incoming message. | The third Incoming Message is triggered at Flow 2 and the receive node is waiting. Flow 1 and Flow 3 are not triggered. | |
| User sends a Webhook trigger followed by Postback response and Incoming message. | User sends a Postback response. | Flow 1 is triggered and the receive node is waiting. Flow 3 is waiting at receive node. Flow 2 is not triggered. |
| User sends a Postback response. | Flow 1 is triggered and the receive node is waiting. Flow 3 is waiting at receive node. Flow 2 is not triggered. | |
| User sends an Incoming message. | Flow 1 is not triggered and the receive node is waiting. Flow 3 is not triggered and the receive node is waiting. Flow 2 is triggered and the receive node is waiting. | |
| After time-out. | Flow 1 ended with onTimeout at receive node. Flow 3 ended with onTimeout at receive node. Flow 2 ended with onTimeout at receive node. |
Scenario 2 - with Two Services
| Service 1 | Service 2 |
|---|---|
| Flow 1 - Start node event type (Postback for channel). Receive node waiting on ‘Incoming message’ as event type. | Flow 4 - Start node event type (Post back for channel). Receive node waiting on ‘Incoming message’ as event type. |
| Flow 2 - Start node event type (Incoming message for channel). Receive node waiting on ‘Incoming message’ as event type. | Flow 5 - Start node event type (Incoming message for channel). No Receive node. |
| Flow 3 - Start node event type (Inbound Webhook) and a Receive node waiting on ‘Incoming message’ as event type for a channel. |
The behavior of the flows is illustrated in the following table:
| User’s Messaging Behavior | Scenario breakdown | Behavior |
|---|---|---|
| User sends a Postback message followed by two Incoming messages, one after the other | User sends a Postback message. | Flow 1 in service 1 and Flow 4 in service 2 are triggered and the receive node is waiting. Flow 2 and Flow 3 in service 1 and Flow 5 service 2 are not triggered. |
| User sends an Incoming message. | Flow 5 in service 2 is triggered and ended successfully. Flow 2 in service 1 is triggered and the receive node is waiting. Flow 1 in service 1 is not triggered and the receive node is waiting. Flow 4 in service 2 is not triggered and the receive node is waiting. Flow 3 in service 1 is not triggered. | |
| User sends another Incoming message. | Flow 2 is continued and ended successfully. Flow 5 in service 2 is triggered again and ended successfully. Flow 1 and 4 are waiting at receive node. Flow 3 in service 1 is not triggered. | |
| After time-out. | Flow 1 and Flow 4 ended with onTimeout at receive node. | |
| User sends three Incoming messages one-by-one. | User sends first Incoming message. | Flow 2 is triggered and the receive node is waiting. Flow 5 is triggered and ended successfully. Flow 1 and 4 are not triggered. |
| User sends second Incoming message. | Flow 2 is triggered with Incoming Message 1 is continued and ended successfully with Incoming Message. Flow 5 is triggered and ended successfully. Flow 1, 3 and 4 are not triggered. | |
| User sends third Incoming message. | Flow 5 is triggered and ended successfully. Flow 2 is triggered as a new transaction and the receive node waiting. Flow 1, 3, and 4 are not triggered. | |
| After time-out. | Flow 2 ended with onTimeout at receive node. | |
| User sends a Webhook trigger followed by Postback and Incoming message. | User sends a Webhook trigger. | Flow 3 gets triggered and the receive node is waiting. Flow 1, 2, 4, and 5 are not triggered. |
| User sends a Postback message. | Flow 1 and Flow 4 are triggered and the receive node is waiting. Flow 2 and Flow 5 are not triggered. Flow 3 is not triggered and the receive node is waiting. | |
| User sends a Incoming message. | Flow 2 gets triggered and the receive node is waiting. Flow 5 is triggered and ended successfully. Flow 1, 4, and 3 are not triggered. | |
| After time-out. | Flow 1 ended with onTimeout at receive node. Flow 3 ended with onTimeout at receive node. Flow 2 ended with onTimeout at receive node. Flow 4 ended with onTimeout at receive node. |
Updated about 1 month ago