для Cisco Cisco Unified Customer Voice Portal 10.5(1)

Many voice applications require actions to occur “behind the scenes” at some point in the call. In these 
cases, the action does not produce VoiceXML (and thus has no audible effect on the call) or make a 
decision. Instead the action makes a calculation, interfaces with a backend system such as a database or 
legacy system, stores data to a file or notifies an outside system of a specific event. All of these processes 
are built into Action Elements. 

Like decision elements, action elements encapsulate business logic. Action elements are used to 
“modularize” actions that are not related to either producing a configuration for a voice element or 
making a decision. By keeping action elements and decision elements separate, the work of building a 
voice application can be easily divided among many developers. Additionally, isolating an action 
enables it to be modified or skipped without affecting any other elements or the application call flow. As 
with decision elements, an action element may also utilize a fixed or dynamic configuration, or no 
configuration at all. Similarly, the configuration contains only settings and sets variables. 

A few examples of action elements could be one which retrieves, manipulates and stores the current 
stock price for a particular symbol passed in the configuration. Another example might be to notify a 
customer care administrator if a caller issues a trouble ticket. 

CVP VoiceXML Server bundles some pre-built action elements with CVP VoiceXML Server to simplify 
commonly needed tasks such as sending e-mails and accessing databases. 

One tool an application developer needs at his disposal is a mechanism where the activities of callers can 
be analyzed to determine which part of the application is the most popular, creates confusion, or 
otherwise is difficult to find. To do these analyses, the developer would require knowledge on whether 
a caller (or how many callers) reached a certain point in the application call flow. This check may also 
be done within the call itself, changing its behavior dynamically if a caller visited a part of the 
application previously. To do this, the developer would use Flag Elements. 

Flag elements can be seen as “beacons” which are triggered when a caller visits a part of the call flow. 
The application developer can place these flag elements anywhere in the call flow he wishes to track. 
When the flag is tripped, the application log is updated so that post-call analysis can determine which 
calls reached that flag. The flag trigger is also stored within the call data so an application can make 
decisions based on flags triggered by the caller. 

As with action elements, flag elements have a single exit state and do not affect the call flow whatsoever, 
though do not have a configuration. 

Encapsulates business logic that performs tasks 
not affecting the call flow (i.e., has only one exit 
state). 

Records when a caller reached a certain point in 
the call flow.