Branching the action flow based on the channel
The system enables the use of the same action rule for both inbound and outbound channels. You can build distinct paths of flow execution based on the channel. This functionality facilitates the use of the system by inbound applications (such as NBAA) to process their customer offerings.
The system enables this inbound channel support functionality in the following two ways:
- When an inbound request is received (for a specific action and customer), the system first
determines whether the specified action is already in flight for the specified customer in
the specified context. If so, the particular action is loaded and flow execution is forced
down the Inbound path. This is done by the use of the InboundTicket construct. The
InboundTicket can be associated with most flow shapes (with the exception of the Start shape
and the Wait shape). This ticket denotes the place in the flow where processing should jump
(switch to) when an inbound request is received for an in-flight action.
The InboundTicket is enabled by specifying it as the value for the Ticket Name in the Tickets section (under Advanced ) of the appropriate flow shape, as shown below.
Note: To avoid ambiguity in flow execution, the InboundTicket should be specified on only one shape in a flow.
- On the other hand, if the specified action is not currently in-flight for the specified
customer and context, the system creates a new action object and starts executing the flow
on it, in the context of the channel that was part of the inbound request. If there’s a need
to have separate processing paths for different channels (say Inbound vs. Outbound, or Call
Center vs. ATM), this can be achieved by branching the flow on Channel at the appropriate
In the flow snippet above, the flow execution is initially branched based on the channel. If the channel on the input request is Call Center, the flow goes down the Record Response route – in this case, the customer is responding to the action in the Call Center, and there is no need to send them the action email. For all other channels, we send the action email and wait for either the customer to respond or the wait duration to expire.
Both the scenarios, outlined above, should be handled in an action if it needs to support requests on an inbound channel. Thus, such an action should have both:
- A shape designated as the resumption point for inbound requests by having the InboundTicket set on it
- A branch in flow execution for channel-specific paths (as needed)
Previous topic Understanding Response Received connectors Next topic Grouping offerings into action bundles