hasRemoteSubfields custom field renders empty in workflow template instances despite identical /subfields response

Context: Test app v13 draft, custom block + custom field type pattern adopted from a legacy migration-wizard output.

Affected feature:

• Custom field type with hasRemoteSubfields: true
• Action block referencing that field type
• Workflow template (created manually via Developer Center)

Issue:
When a user instantiates the template and clicks the field's sentence placeholder, the picker shows "No options available".
When the user builds the same action manually in the from-scratch builder (same trigger + same action), the picker renders the expected inline mapping form populated with the board's columns.

Evidence (network-layer identical):

Both code paths make the same POST to /automations-ms/framework/subfields with body:

{

"fieldTypeReferenceId": <our-field-type-id>,

"credentialsValues": {},

"dependencyValues": { "boardId": { "value": <board-id>, "fieldKey": 10380086 } },

"deprecatedIntegrationApiValues": { "dependencyMetadata": { "boardId": {} } }

}

Both receive the same 200 response — a JSON array of {key, title, type: "primitive", primitiveType, isNullable, isOptional, isArray} entries representing the board's columns.

Despite identical request + response, the UI renders differently between the two contexts.

Reproduction:

1. Open a board's Automations.
2. Path A (works): Pick a trigger + the action from scratch → click the sentence placeholder for the custom field → inline form populates with all column slots.
3. Path B (broken): Pick the workflow template that includes the same trigger + action → click the placeholder → "No options available".

What we already tried:

• Diffed our template's manifest structure against a working migration-wizard-produced template. Matched:
  • workflowBlocks[i].contextsData.lite_builder.sentence and sourceConfig
  • inboundFieldsSourceConfig.<mappingField>.workflowVariableKey: 3 with variable 3 intentionally undefined in workflowVariables (mirrors the wizard output)
  • Removed extraneous top-level contextsData and mfValidated
• Confirmed /framework/options and /framework/subfields calls succeed at every step, with identical bodies between Path A and Path B.

Hypothesis: the UI handles manually-created workflow templates differently from wizard-migrated templates (which carry migrationEntityId/migrationId). The from-scratch builder appears to use a different render path that correctly handles the subfields response.

Asks:

1. Is there a manifest field or property required for manually-created templates to render hasRemoteSubfields correctly?
2. If not — please investigate the UI behavior gap.