Common Module invocation syntax in Architect JSON

Architect & Flows
1

Could someone explain the correct JSON structure for invoking a shared Common Module from multiple inbound flows.

I am trying to reuse a flow but the standard Action definition is unclear. Do I use a specific action type or a direct reference in the flow definition?

2

Take a look at at the flowId reference pattern instead of hardcoding actions, as it resolves scope conflicts in shared modules.

Error: Invalid action type ‘InvokeFlow’ in node definition.

{
 "id": "invoke_common_module",
 "type": "InvokeFlow",
 "flowId": "{{commonModuleId}}"
}
3 
{
 "type": "InvokeFlow",
 "flowId": "shared-module-id",
 "data": {
 "inputVar": "{{triggerData.input}}"
 }
}

The suggestion above is correct, but you must explicitly map input variables in the data block, otherwise the shared module receives null context and fails validation during execution.

4

The documentation actually says InvokeFlow requires explicit input mapping. The suggestion above is correct, but you must pass variables through the data block. Missing this causes the shared module to receive null context, triggering validation errors during execution.

Here is the minimal repro structure for the node definition. Ensure input keys match the target flow’s inputs exactly.

{
 "id": "invoke_common",
 "type": "InvokeFlow",
 "flowId": "{{commonModuleId}}",
 "data": {
 "input": {
 "crmId": "{{contact.attributes.crmId}}"
 }
 }
}
5

TL;DR: Use explicit data mapping in the InvokeFlow node to prevent context loss.

I usually solve this by enforcing strict variable mapping in the data block. The suggestion above is correct regarding the structure, but you are missing the critical step of defining the input schema. If the target Common Module expects specific variables, and you do not map them explicitly in the invoking flow, the execution context will be null. This triggers a validation error before the module even runs.

Here is the correct node definition structure. Note the data object mapping:

{
 "id": "invoke_common_module",
 "type": "InvokeFlow",
 "flowId": "{{commonModuleId}}",
 "data": {
 "customerName": "{{triggerData.customer.name}}",
 "orderId": "{{triggerData.order.id}}"
 }
}
  1. Define the flowId as a reference to the shared module ID.
  2. Map every required input in the data block.
  3. Ensure keys in data match the target flow’s input definitions exactly.

Missing this mapping causes the shared module to fail silently or throw a validation error. The Architect engine does not infer variable types from context. You must be explicit.

I have seen this issue repeatedly in large-scale deployments where teams copy-paste flow definitions without updating the data bindings. The result is broken shared modules that appear to work in isolation but fail in production when invoked from different sources.

Test the invocation with a debugger step before deploying. Verify that the variables are populated correctly. This prevents downstream errors that are difficult to trace.