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:

1. 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.
2. 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 place.

   

   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)