Calling shared Common Module flow from multiple inbound flows

Architect & Flows
1

I’m building a new custom desktop app using the Embeddable Client App SDK and I need to trigger a specific data action based on the active flow. The client wants a single ‘Common Module’ flow that handles the initial greeting and data lookup, which then gets called by multiple different inbound call flows.

My question is about the API side of this. In the Architect Data Action, I’m trying to pass the flowId from the current interaction to the shared flow. I’m using the GenesysCloud.ClientAppSdk to get the current interaction context. Here is the code I’m using to fetch the flow details:

var interactions = await client.InteractionsApi.GetInteractionsAsync(...);
var currentFlowId = interactions.Interactions[0].Flow.Id;

I then pass this currentFlowId as a parameter to the Common Module flow via a REST call to /api/v2/architect/flows/{flowId}/execute. The issue is that when the Common Module flow starts, it doesn’t seem to have access to the original interaction’s data. Is there a specific way to link the new flow execution to the existing interaction so the data persists? Or am I missing something in how the SDK handles flow contexts?

2

Hey, I see where you’re going with this, but calling a flow from a Data Action isn’t really how Architect is designed to work. You’re mixing up execution contexts. Data Actions are for transforming data within a single flow instance. If you want to hand off to a “Common Module,” you need to use the Transfer or Launch Flow action, not a Data Action.

The tricky part with shared flows in Genesys Cloud is that they don’t automatically inherit the context of the caller unless you explicitly pass it. If you just launch the shared flow, you might lose the conversation history or custom attributes.

Here’s the pattern I use. In your inbound flows, instead of a Data Action, add a Launch Flow step. Point it to your Common Module flow ID. Then, in the Common Module flow, make sure you have a Start node configured to accept parameters. You’ll need to map the flowId and any other critical data (like conversationId) in the Launch Flow step’s parameter mapping.

If you absolutely must do logic before the handoff, use a Data Action to calculate the target flow ID dynamically, then pass that ID to the Launch Flow action. But don’t try to execute the flow inside the Data Action.

Also, watch out for state drift if you’re managing this via Terraform. The genesyscloud_flow resource handles dependencies, but referencing flows by name can be brittle if you rename them. Use the flow ID directly in your HCL or a local variable map.

locals {
 common_flow_id = data.genesyscloud_flow.common_module.id
}

resource "genesyscloud_flow" "inbound_sales" {
 # ... config ...
 steps {
 type = "LaunchFlow"
 action {
 type = "LaunchFlow"
 flowId = local.common_flow_id
 # Pass context
 parameters {
 name = "sourceFlowId"
 value = "FlowId" # Built-in variable
 }
 }
 }
}

Just remember, the launched flow runs in a new execution context. Any variables set in the parent flow won’t be there unless you pass them as parameters. It’s a common gotcha.

3
  • Skip the data action entirely and use the Launch Flow step in Architect instead.
  • Pass the required data via the inputs map so the common module actually receives the context.
  • You’ll need to define the output variables in the shared flow to get the results back cleanly.