Start Scenario Step

Builds in a versioned child scenario as a reusable, self-contained block within the current flow.

What it does

• Embeds a selected scenario inside the current one as a versioned child block, rather than triggering it as a separate execution.
• Runs the child scenario in-place and returns its outputs to the parent flow.
• Uses a fixed (versioned) snapshot of the child scenario, ensuring stability and predictable behavior.
• Allows you to safely reuse tested logic across multiple scenarios.
• Supports rollback by switching to a previously working version of the child scenario if needed.

When to use it

• To reuse shared logic (like normalization, enrichment, notifications) across multiple parent flows.
• To keep complex projects modular—separate channel-specific or customer-specific logic into child scenarios.
• When you want predictable execution that won’t break if the child scenario changes later.
• When different teams maintain different parts of logic, but you need to integrate them safely.

How to configure

1. Select Scenario

Choose which scenario you want to embed as a child.

• Scenario dropdown displays all available scenarios in your workspace.
• Select the one that contains the logic you want to reuse.
• This scenario must be already created and saved.

Why it matters: You are not calling an external process—you are embedding this scenario’s logic directly into your current flow.

2. Select Version

Define which version of the child scenario should be used.

• Latest — always uses the most recently saved version.
• Fixed version — select a specific version number.

Best practice:

• Use Fixed version in production to avoid unexpected breaking changes.
• Use Latest during development for faster iteration.

Why it matters: This ensures your flow remains stable even if the child scenario evolves later.

3. Input Mapping

Provide data from the parent scenario to the child scenario.

• Map parent data into the child’s expected inputs.
• You can reference root input (data.*) or outputs of previous steps (steps.<stepId>.outputs.*)
• Each input field corresponds to a parameter expected by the child scenario.

Why it matters: The child scenario runs with its own input schema, so you must explicitly pass all required data.

4. Output Usage

After execution, the child scenario returns outputs that can be used in the parent flow just as another step in your main scenario.

Typical patterns

• Fan out to dedicated subflows per marketplace or region, then merge results.
• Call a shared enrichment routine that standardizes objects for downstream systems.
• Trigger a downstream integration maintained by another team while keeping the parent flow simple.