Skip to main content
Every journey is built from a base template — the starting definition of the workflow. Overlays let you modify that base behavior for specific scenarios (variants, customer-specific flows, edge cases) without losing the relationship to the original. Instead of duplicating a journey and maintaining two copies, you maintain one base and as many overlays as you need.

​
When to use it

  • You have a core workflow (e.g., a standard checkout flow) and need a version with different values or slightly different behavior for a specific customer or edge case.
  • You want to test error paths or alternative flows without creating completely separate journeys.
  • You need environment-specific or customer-specific variants that should stay in sync with the base as it evolves.

​
Key concepts

  • Base template — the foundational journey definition. It defines the steps, request templates, assertions, and default value configuration.
  • Overlay — a set of modifications applied on top of the base. An overlay can override values, adjust step configuration, or add behavior — but it retains a link to the base. A journey can have any number of overlays.
  • Relationship — overlays stay connected to their base. When the base changes, overlays inherit those changes except where they explicitly override them. This keeps variants in sync without manual upkeep.

​
How it works

The base template is what you define when you build a journey normally. It represents the canonical version of the workflow. Creating an overlay creates a new variant derived from that base. In the overlay, you can:
  • Override specific value sources (e.g., use a different run input or a different secret reference)
  • Substitute step configuration for specific steps
  • Modify assertions for the variant scenario
Fields not overridden in the overlay inherit from the base. If you update the base (add a step, change a template), overlays pick up that change unless they’ve explicitly overridden it.
Overlays are useful for customer-specific flows and edge cases. For reusable value configurations (like “happy path” vs. “expired token”), consider Cases — they’re lighter-weight and work across base and overlay alike.

​
Examples

Scenario: Standard checkout vs. gift card checkout
  • Base: checkout-flow — standard checkout with credit card.
  • Overlay: checkout-flow / gift-card — overrides the payment method value; all other steps and assertions inherit from the base.
When the base adds a new step (e.g., fraud check), the overlay automatically includes it. No manual sync required. Scenario: Customer-specific API behavior
  • Base: create-subscription — the standard subscription creation flow.
  • Overlay: create-subscription / enterprise-customer-A — overrides the plan_id and billing_cycle values with customer-specific inputs; adds an assertion on the response features array.

Cases

Save named value configurations for testing — a lighter-weight alternative to overlays for data variation.

Values panel

Configure value sources for the base and overlays.

Build mode

Overview of the Build-mode canvas and panels.

Journey concepts

The mental model behind journeys and how they compose.