I must respectfully disagree with Deepak here.
The Call Subflow step is probably the most error-prone and difficult to troubleshoot step in the palette. It is very common to see people pull hair out over this step for two reasons:
- There is no validation of whether the input/output variable mappings will work at runtime. For example, if the parent script is expecting a String but the child script uses an integer. This will pass validation in the editor but throw an exception at runtime.
- Reactive debugging of a script does not include the sub flow script which executes a single step, pass fail. If there is a problem within the child script that Call Subflow referenced you must debug it separately. This also requires additional code so that you can attach it to a test Application, accept a JTAPI Triggering Contact only in debug mode, and manually set any variables that would normally be set through the input mappings.
The most common use cases I see for sub flows in the field are places where highly reusable code will be shared across either multiple scripts within the same system or across multiple installs. For example, most holiday checking logic is implemented as a sub flow: it's self-contained and fairly well understood by an engineer after they build it the first time.
Additionally, the child script within the Call Subflow step continues to increment the Maximum Step Count iterator which caps a script at 1000 step executions. A Call Redirect to another application and script resets that counter.
In fact, since CCX continues to lack a clean "which menu option did the caller press"-style report all these years later, it is fairly common to use the Call Redirect to separate JTAPI Triggers on the same application to track this. In practice this turns into a Switch step with a bunch of Goto labels that jump forward in the script to pick up where the menu step would have logically of advanced to. The difference is that now there will be an incremented value per-trigger on the Application Summary report.
So, at least in my opinion, Call Subflow is roughly analogous to a programming function or library: it does a specific task and is reusable. The Call Redirect to another application/script is far more common when you are changing from one call flow to another. Just be careful that the Call Redirect destination matches the JTAPI Trigger exactly and not a CUCM Translation Pattern or some other middleman. If CCX expects the call to hairpin back to itself it will hold memory open. If CUCM delays or never sends that call back then you have a memory leak.
PS- There is actually a third step that should have been an amazing addition to this topic but Cisco really dropped the ball when they coded it: Trigger Application. It was added in the 7.x days and at first several of us CCX nerds were really excited about it. Not long after a fundamental problem surfaced though: when called synchronously it is unpredictable how exception handling will play out. In random instances the On Exception logic would be caught by the original script but other times it would be caught by the triggered script. There is no clean break, nesting or precedent. It is so handicapped by this that that you can really only use it in the very rare circumstance where you can trigger an application asynchronously. It was a sad day when that answer came down from the DE.
