Showing results for 
Search instead for 
Did you mean: 


Pros and cons of CVP subflows

Hello All,

Are there any pros and cons of using CVP subflows from a CVP application architecture and performance standpoint?

As per my understanding of how the subflows works in CVP, following are the pros and cons of subflow over subdialog:


  • Resides locally in the app, so session data is easily accessible for call processing
  • Multiple developer can work concurrently on the app by splitting the flow in logical groups (sub flows). Very useful for agile delivery.


  • A change in a sub flow requires the sub flow to be re-deployed in the calling app. So, if a sub flow is used across apps, either all the calling apps may need to be deployed or multiple versions of subflows needs to be maintained for each app.

Other than the above, I am interested to know if there are any specific pros and cons (especially Con) because we plan to use the subflows extensively in our CVP application architecture.

Any thoughts, comments and suggestions are really appreciated.

Thanks & regards,



Hello Mohini,

Thanks for sharing the link, it was very helpful to understand the CVP subdialog option. However, there is nothing specific mentioned about the CVP subflows in that thread which is a new concepts introduced in CVP 10.5

Any information/link which provides details about subflows specifically (pros/cons/impact etc..)?

Also request other in the community to comment based on their experience with CVP Subflows.

Thanks & regards,


Hey Roshan, did you end up using Sub flow or subdialogs?  One deal breaker for me was inability to re-use subflows across multiple CVP applications, it seems the subflows must be nested under a specific CVP app.  We use subdialogs because of this limitation.

Which is a bummer because as you mentioned a subflow would keep the transfer local to VXMLServer vs sending a new VoiceXML page to the gateway and opening another session with another app when doing a subdialog. There has to be a performance overhead to doing that, however small it may be.

I've found the following 'features' with subflows. None are

deal-breakers, but nice to know!

a. Because element data and local data are only available within a

subflow, they are not available in the End of Call Java class where you

might be trying to access them for reporting.

b. However, element data and local variables are 'persistent' - so if

you call a subflow multiple times, all its variables will RETAIN their

previous values. This is important if using something like Counter

element - it will NOT initialize the 2nd time you call it.

c. An application transfer fails from within a subflow, however

CVP_Subdialog_Return works fine

d. If using getElementHistory() and getExitStateHistory() in End of Call

Java, they do not align correctly for elements within the Subflow - it

seems the SubflowCall element has no exit state until you exit the

subflow, at which point things seem to align correctly again!

e. If using getElementHistory() within a subflow, the element names

include the name of the subflow SubflowName.ElementName. However, if

you then try to use this with the getElementData() method, it fails

because it wants to know 'JUST' the name of the element, so you must

strip off the subflow name.

Wow thanks Janine, that is super helpful to know upfront!

Recognize Your Peers
Content for Community-Ad