Data type information lost when workflow_input passes data to child workflow start_trigger

[PlaneInABottle]

Problem

When a workflow_input block calls a child workflow with start_trigger, data types are not preserved during the handoff. Complex objects arrive as stringified JSON, numeric IDs become strings, and boolean fields become string representations.

Root Cause - DUAL ISSUE FOUND

Issue 1: Object stringification during variable resolution

File: /apps/sim/executor/variables/resolver.ts:150 + /apps/sim/executor/variables/block.ts:182-184

The variable resolver's resolveTemplate() function always returns string, which causes:

• When inputMapping contains references like "field": "<webhook.sender>" where sender is an object
• The resolver calls formatValueForBlock() which JSON.stringify's the object
• Result: sender arrives as a JSON string instead of a parsed object

// resolver.ts:150 - Always returns string
private resolveTemplate(...): string {
  // ...
  return this.blockResolver.formatValueForBlock(resolved, blockType, language)
}

// block.ts:182-184 - Stringifies objects
if (typeof value === 'object' && value !== null) {
  return JSON.stringify(value)  // Objects become strings
}

Issue 2: Typed inputs overwritten in child workflow

File: /apps/sim/executor/utils/start-block.ts:266-281

Even when coerceValue() successfully converts stringified objects back, buildUnifiedStartOutput() overwrites the coerced fields.

Impact

Example: Parent Workflow → Child Workflow

// Webhook sends:
{ "conversation_id": 149, "sender": { "id": 10, "email": "user@example.com" } }

// Child workflow receives:
{
  "conversation_id": "149",
  "sender": "{\"id\":10,\"email\":\"user@example.com\"}"
}

// Blocks fail:
<start.sender.email>  // undefined (sender is string, not object)
<start.conversation_id> == 149  // false (string !== number)

Steps to Reproduce

1. Create Parent Workflow with generic_webhook trigger

   • Configure inputFormat with types: conversation_id (number), sender (object with nested properties)

2. Create Child Workflow with start_trigger

   • Define matching inputFormat schema

3. In Parent Workflow, add workflow_input block calling Child Workflow

   • Set inputMapping: {"conversation_id": "<webhook1.conversation_id>", "sender": "<webhook1.sender>"}

4. Send test webhook with structured data:

   {
     "conversation_id": 149,
     "sender": { "id": 10, "email": "user@example.com" }
   }

5. Inspect Child Workflow's start block output

Expected Behavior

• conversation_id: 149 (number)
• sender: { id: 10, email: "user@example.com" } (parsed object)
• Block references like <start.sender.email> work correctly

Actual Behavior

• conversation_id: "149" (string)
• sender: "{\"id\":10,\"email\":\"user@example.com\"}" (JSON string)
• Block references fail with undefined values

Affected Use Cases

• Multi-workflow templates where data flows between workflows
• Generic webhooks triggering child workflows with typed inputs
• Any architecture where parent passes complex objects to child workflows
• Templatable workflows reused across different companies/configurations

Severity

High - Blocks multi-workflow patterns and templatable workflow architecture. Cannot pass typed data between workflows reliably.