The 08:00 JST deployment window hit a snag with the new shared logic pattern. We are trying to consolidate the IVR menu logic into a reusable module to keep the inbound call flows clean. The goal is simple: call a single shared flow from three different inbound routing strategies.
The module is published and active. I’ve verified the inputs match. When the inbound flow hits the Module action, it crashes immediately with a 500 Internal Server Error in the execution logs. The error payload suggests a scope issue, but the variables are defined in the parent flow’s context.
Here is the module definition JSON I’m pushing via the API:
{
"id": "mod_shared_menu_v2",
"name": "Shared Menu Logic",
"inputs": [
{ "name": "agentSkill", "type": "STRING" }
],
"outputs": [
{ "name": "destination", "type": "STRING" }
]
}
And this is the action node in the main flow:
{
"type": "MODULE",
"moduleId": "mod_shared_menu_v2",
"inputMappings": {
"agentSkill": "{{flow.agentSkill}}"
},
"outputMappings": {
"destination": "{{module.destination}}"
}
}
The log trace shows the module starts, fetches the variable, then dies. No timeout. Just a hard fail.
I tried swapping the variable reference to {{global.agentSkill}} just to test. Same result. The inputMappings seem to be the culprit. The documentation says parent scope variables are accessible, but it looks like the module runner doesn’t see them unless they are explicitly passed in the initial session payload, which we don’t control for inbound calls.
Is there a specific syntax for mapping parent flow variables into a module input? Or is this a known limitation with version 1.29.0 of the platform? The previous version 1.28.0 didn’t have this module feature, so I’m stuck guessing.