Workflow Logging v2

The Runtime records each Step in a Workflow execution including capturing Parameters, Returns, timing, result, errors, and parent/child context. Deferred values remain live while they are consumed, so their log state can continue changing after a Node Method returns.

Capture lifecycle

A Step row begins when invocation starts. It can then record:

The authored Step, Node, and Method identity.
Start time and elapsed duration.
Parameter and Return previews.
Completion, failure, Stop, stale, or incomplete state.
Error information.
Workflow, instance, parent, and child identifiers.

For a scalar, capture normally completes with the invocation. For a Stream or deferred enumerable, the runtime wraps the value and observes consumption. The log can show bytes, record counts, bounded previews, and whether the consumer completed the source.

Deferred values and counters

When evaluation of a return is deferred (because it is required by a later step), the logs will show that execution has progressed to further steps before the log of the return becomes available.

A counter of records processed (for collections) or bytes processed (for streams) will also be shown on the log and will increment as it is consumed.

Previews and full values

The log table shows Property previews - usually the first few KB of data for the log. When you download or open a large value in the Console, it will automatically obtain the large value using a detail log API.

Very large Properties are truncated in Workflow logs. Logs are diagnostic records, not permanent data storage. If you need the complete value, use a suitable Workflow Step to save it to a database or another durable store.

Redaction

Logging.Redact: true excludes a selected Workflow Property from log content. Root deferred redaction preserves lifecycle state but stores (Not Logged) and does not contribute its byte or record counts. Individual properties within a schema can also be tagged as redacted. When this tag is applied to a container element, all child elements are automatically redacted.

Redaction does not change the runtime value or automatically sanitize Debug Returns, exception messages, custom Node log text, diagnostics, or external destinations. See Workflow Log Redaction.

Parent and child execution

Sub-Workflow Steps share traceable instance context with their child execution while retaining separate Workflow identity, state, placement, and published artifact. Use parent/child log views to follow the call boundary and the child rows.

HTTP, MCP, Schedule, listener, App, and designer invocations all produce Workflow logs, but their surrounding request or host diagnostics can differ.

Search and operational use

Use designer Logs for the current Debug and recent activity for one Step. Use the global Workflow Logs screen for broader Workflow, instance, Node, time, error, parent/child, and indexed-content searches.

Keep Step names meaningful and stable. Use Property redaction for sensitive fields, inspect actual input/Return columns, and correlate provider-side evidence when a Node performs an external operation.