Common Module reuse - how to call a shared flow from multiple inbound call flows

Architect & Flows
1

Symptom

Noticed a weird routing loop yesterday. Calls drop after the third retry. Doesn’t make sense.

Configuration

Running Genesys Cloud v2024.10 with Architect UI. Trying to reuse a common module across three inbound flows. Reference block looks like this:

{
 "type": "subflow",
 "entityId": "8912-4421-0091-2211",
 "timeout": "PT30S"
}

Error

The POST /api/v2/architect/flows call throws a 400 Bad Request. Validation complains about circular dependencies. Module only plays a prompt though.

Question

How do you properly structure the reference object when multiple flows trigger the same common module? It’s frustrating how the docs keep shifting between subflow and common-module syntax.

2

Sounds like you’re hitting the reference block timeout. It’s not a loop, it’s the system giving up before the common module finishes.

Check the timeout setting on that reference block. Default is usually too short for a heavy shared flow. Set it to 60 seconds or higher. Also, make sure the common flow has a clear end condition. If it hangs, the parent flow waits until it times out, then retries. That’s your “third retry” drop.

We’ve seen this with Teams direct routing too. The SBC drops the leg if the signaling takes too long. Same principle here. Architect just needs more time to process the shared logic.

Try this:

  1. Open the reference block.
  2. Set timeout to 120s.
  3. Add a “Set Variable” block at the start of the common flow to log entry time.
  4. Add another at the end to log exit time.

Check the logs. If the gap is huge, your common flow is too heavy. Break it up.

3

Stop managing flows in the UI. It’s a maintenance nightmare. Use the Genesys Cloud Terraform Provider to define your shared flows as modules.

resource "genesyscloud_routing_flow" "shared_common" {
 name = "Common Logic"
 # ... config
}

This forces version control and prevents accidental timeout tweaks. You can reference the flow ID in other modules using genesyscloud_routing_flow.shared_common.id. Keeps everything declarative and auditable.

4

is spot on. The timeout was the culprit, but it’s not just about bumping the number. You have to make sure the common flow actually exits cleanly. If it hangs on a wait block or a bad condition, the parent flow just spins until it dies.

I built a simple status widget for our internal portal that polls /api/v2/routing/queues/realtime, and I learned the hard way that shared logic needs strict boundaries. Here’s what fixed it for me:

  1. Set the reference block timeout to 90 seconds. Default is too aggressive for any flow with IVR menus.
  2. Add a Transfer block at the end of your common flow. Don’t just let it “end”. Explicitly transfer to a queue or disconnect.
  3. Check the Return Data settings. If you’re passing variables back, make sure the types match. Mismatched types cause silent failures that look like timeouts.
// Example of how we poll the status to catch these hangs in real-time
const checkFlowHealth = async (flowId) => {
 const res = await fetch(`/api/v2/architect/flows/${flowId}`, {
 headers: { 'Authorization': `Bearer ${token}` }
 });
 const flow = await res.json();
 return flow.status === 'PUBLISHED';
};

Don’t forget to publish the common flow after changes. It’s a rookie mistake, but it happens.

3 Likes