Custom "Jump to Flow" module

1. Brekeke Product Name and Version:
Brekeke PBX, Version 3.17.2.7, Multi-Tenant

2. Java version:11.0.29

3. OS type and the version:Linux 6.8.0-1028-oracle

4. UA (phone), gateway or other hardware/software involved:

5. Your problem:
The current default "Jump to Flow" module requires manual configuration of properties (e.g., Target Flow ID, Input Variables, Environment Tags) for every implementation. This repetitive process is time-consuming and increases the risk of configuration errors during flow development.

Expected Outcome: I want to create a custom "Jump to Flow" component that automatically assigns IVR properties to the target modules upon jumping.

Questions:

1. Is this requirement technically feasible?

2. If feasible, what would be the best implementation strategy to achieve this?

Hi,

I recommend you creating your custom module template.
As you can see in the Module Template Setting - General / Jump to Flow > Basic Settings > [SCRIPT] section, in the original "Jump to Flow Module" template, the set Flow Name and Properties values are passed to the variables flowname and properties before executing it like this:

var flow = $runner.getProperty("flowname");
var params = $runner.getProperty("properties");
return $runner.exec( flow, params );

For your new customized Module template, you should modify this section to reference the values set in the IVR properties instead.
For example, if you have configured the [Properties] field of the IVR Extension as follows:
next-flowname=sampleflow

You can reference that value by writing the following in your module template:
var flow = $runner.getProperty(".next-flowname");

Regards,

Hi Brett,

Thank you for your suggestion.

I have already completed this part by modifying the script to reference the values from the IVR properties, and the jump to the sub-flow is working correctly.

However, I am currently facing another issue.

After jumping to a sub-flow, the Custom Jump module is not able to obtain the result returned from that sub-flow. Because of this, I cannot use the sub-flow result for the next processing steps.

For example:

The Custom Jump to Flow module jumps to sub-flow A, and sub-flow A returns the result A1.
I would like to use A1 to determine or execute the following sub-flows.

Could you please advise what is the recommended way to pass the result from the executed sub-flow back to the parent (main) flow so it can be reused after the jump?

Thank you for your support.

Best regards.

Hi,
Sorry, I have no idea about that.
I recommend you ask Brekeke tech support.

Regards,

Hi Brett,

Thank you again for your guidance.

I have one additional concern related to performance.

We observed that when the call flow runs normally (without using Jump to Flow), the processing time is noticeably faster.
However, after introducing the Custom Jump to Flow mechanism, the same logic executed inside sub-flows becomes significantly slower.

From the logs, the total call duration increases even though the functional steps are almost identical.

Do you know if there is any overhead internally when $runner.exec() is used to jump between flows?

If so, is there any recommended best practice to minimize the delay?
For example:

- preferred way to pass parameters

- reducing context reinitialization

- caching IVR variables

- or any architecture guideline when designing many sub-flows.

Any advice or reference would be greatly appreciated.

Thank you for your support.

Best regards,

Hi Thanh,

I've had a similar experience. I don't know the exact internals, but from what I've seen, the more sub-flows you chain together, the slower it gets. It feels like each jump adds a bit of overhead that adds up quickly.

What worked for me:

Keep sub-flow nesting shallow — try not to go too many levels deep with $runner.exec()
Pass fewer parameters — only pass what you actually need, extra parameters seem to slow things down
Keep logic in one flow when possible — if something doesn't really need to be a separate sub-flow, just keep it in the main flow
It's a trade-off between reusability and performance. Hope that helps!

Regards,