Log Step

Emit custom log/debug events inside a scenario as structured messages for observability and audit trails.

What it does

  • Writes structured log entries into the scenario execution log at the exact point where the step runs.
  • Lets you map dynamic data (for example, payload fields, step outputs, counters, flags) into the log message.
  • Supports log levels (for example, info, warning, error, debug) so you can distinguish regular trace messages from problems.
  • Produces a small, predictable output object that can also be used by later steps if needed.

When to use it

  • When building or changing a scenario and you want visibility into what is happening at each stage.
  • When you need to debug data issues: wrong values, missing fields, or unexpected branches.
  • When you want to record business‑level breadcrumbs, such as “order skipped due to low stock” or “fallback API used”.
  • When you want to help future maintainers understand why a path was taken without reading every condition in detail.

Typical examples:

  • Log the incoming payload at the start of a scenario.
  • Log decisions taken by Conditional / Switch steps (“VIP order route chosen”, “Canceled order – no fulfillment created”).
  • Log the result of an external API call (status code, key parts of the response) before continuing.
  • Log loop progress for Split or While Loop steps (for example, current index, total items, remaining retries).

How to configure

In the Log step configuration:

  • Level

    • Choose the log level that best represents the importance of the message:
      • debug – very detailed diagnostics (usually only needed while building flows).
      • info – normal operational messages (checkpoints, milestones).
      • warning – something unexpected but non‑fatal (fallback paths, missing optional fields).
      • error – something went wrong; usually paired with an Error step or retry logic.
    • Use consistent levels across scenarios so that filtering logs is predictable.

  • Message

    • A short, human‑readable summary of what is being logged.
    • Can be a fixed text or built using variable interpolation depending on UI capabilities (for example, “Order {{ data.orderNumber }} routed to warehouse {{ data.warehouse }}”).

  • Context / Fields

    • Add one or more key–value pairs that will be attached to the log entry as structured data.
    • Each value can be:
      • A mapped reference (for example, data.order.id, steps.check_stock.outputs.available, steps.api_call.outputs.status_code).
      • A literal value (for example, "manual_override", true, 0).
    • Prefer logging only what you need (IDs, statuses, flags) rather than full raw payloads, especially when data might be sensitive.

  • Output mapping

    • Most scenarios do not need to consume the Log step output.
    • If required, you can access it in later steps as something like:
      • steps.log_order_decision.outputs.message
      • steps.log_order_decision.outputs.level
      • steps.log_order_decision.outputs.context