Common Module invocation syntax in Architect Data Actions

• Is it possible to invoke a shared Common Module flow directly from an Architect Data Action without triggering a full transfer, effectively mimicking a Twilio Studio sub-flow execution?
• Current implementation attempts to use the executeFlow endpoint via a REST Data Action, but this results in a 409 Conflict error when the target flow is already in a ‘Running’ state, which is expected behavior but not the desired outcome.
• The goal is to reuse logic for caller ID validation across 15+ inbound flows without duplicating the Assign and Set blocks in each flow’s start node.
• Tried configuring the Data Action to call /api/v2/architect/flows/{flowId}/execute with a JSON payload containing the necessary variables:

{
"variables": {
"callerId": "${contact.caller.phoneNumber}"
}
}

• However, this initiates a new conversation leg rather than pausing the current flow and jumping to the common module logic, causing session state loss.
• Need to know if there is a specific Data Action type or expression syntax that allows for synchronous flow inclusion, similar to how Twilio Studio handles sub-flow references, to maintain the single-leg architecture.

The problem here is conflating execution with invocation. You cannot invoke a flow as a sub-routine via the API. The 409 Conflict error confirms the system prevents duplicate execution contexts for the same flow ID. Architect does not support direct sub-flow calls like Twilio Studio.

You must restructure your logic. Use Data Actions to call external services, not internal flows.

1. Extract the reusable logic into a separate Common Module.
2. Call this module from the parent flow using a Transfer node with Type: Module.
3. Return values via Flow Data.

If you require external API integration, use a REST Data Action. Ensure the target endpoint is idempotent.

This approach avoids state conflicts. Do not attempt to bypass Architect’s execution model with raw API calls for internal logic. It will fail. Use the Transfer node. It is designed for this exact reuse pattern. The REST endpoint is for external systems only. Keep internal logic internal.

Using the executeFlow REST endpoint for internal logic reuse is architecturally incorrect and will inevitably lead to the 409 Conflict errors you are seeing. That endpoint is designed for initiating new, independent interactions (like a callback or outbound campaign), not for procedural sub-routines within an active call flow.

In Genesys Cloud Architect, there is no direct API equivalent to Twilio Studio’s sub-flow execution because Architect flows are stateful and bound to a specific interaction context. However, you can achieve modular logic reuse by leveraging Global Data Actions combined with JSONata or by restructuring your flow into a Common Flow that accepts input parameters.

If you need to execute complex logic that cannot be handled by simple data actions, the standard pattern is to use a Transfer to Flow action with a “Return” action at the end of the target Common Flow. This effectively creates a sub-routine. Ensure the target flow is published as a “Common Flow” (not a standard IVR flow) and configure the Transfer to Flow action to wait for the return.

For pure data transformation or API calls without state management, build a Global Data Action. Here is a structure for a robust Global Data Action definition in JSON:

{
 "name": "CalculateCustomerTier",
 "version": 1,
 "parameters": [
 {
 "name": "totalSpend",
 "type": "number"
 }
 ],
 "returnType": "string",
 "script": "return totalSpend > 1000 ? 'GOLD' : 'SILVER';"
}

This approach avoids the concurrency issues of executeFlow and keeps your logic encapsulated. If you are using Next.js to manage flow configuration via the Platform API, ensure you are using the putFlow endpoint with the correct publish flag to update these common flows without breaking active instances. Remember to validate your parameter types strictly in the SDK to prevent runtime JSONata errors.

My usual workaround is to bypassing the REST API entirely for internal logic reuse, as the executeFlow endpoint is strictly designed for initiating new interaction lifecycles, not procedural subroutines.

Is it possible to invoke a shared Common Module flow directly from an Architect Data Action without triggering a full transfer, effectively mimicking a Twilio Studio sub-flow execution?

The core misunderstanding here is treating Architect flows as stateless API endpoints. They are stateful execution contexts. When you hit /api/v2/flows/{flowId}/execute, you are telling the platform to spawn a new thread. If that flow is already associated with the current interaction context (which it is, if you are trying to “reuse” it within the same call), the platform rightly returns a 409 Conflict to prevent infinite loops or context corruption.

In the Web Messaging SDK, we handle similar state management by maintaining a single WebSocket connection and managing session tokens manually. You cannot “call” a flow; you must route to it.

The correct pattern is to use a Flow Transfer action within Architect, specifically a “Transfer to Flow” step, rather than a Data Action calling a REST endpoint. If you absolutely must trigger this from code (e.g., via a custom integration or external webhook), you cannot use executeFlow. Instead, you must update the interaction’s disposition or attributes to trigger a routing rule that moves the interaction into the target flow.

However, for true “sub-flow” behavior, you should refactor your Common Module into a set of Reusable Data Actions or use Architect’s built-in “Include” pattern (if available in your specific Architect version via drag-and-drop sub-flows). If you are stuck with the current architecture, consider using a Queue Transfer or Skill-based Routing to move the interaction to a secondary flow that contains your common logic, then transfer back. This is verbose, but it respects the platform’s state model.

Here is why the REST approach fails:

// This will fail if the interaction is already bound to a flow context
POST /api/v2/flows/{flowId}/execute
{
 "reason": "subroutine_call" // Invalid semantic for this endpoint
}

Stop trying to force procedural programming paradigms onto a stateful routing engine. Refactor the common logic into a separate flow and use standard transfer mechanisms.

This is caused by conflating execution contexts with procedural calls. Architect does not support sub-routines. See https://support.genesys.cloud/architect/subflow-limitations