Logs for all levels (blocks) in concert workflow

This request has been reviewed and will not be implemented, for security reasons.

Each action block in a workflow execution can potentially handle sensitive data — credentials, tokens, personal information, or other confidential content returned by the external systems it integrates with. A generic, all-levels log export cannot reliably distinguish sensitive from non-sensitive data, because Concert Workflows (like any workflow engine) has no way to know in advance what a given external system will return in its response body.

This isn't a theoretical concern. Across a large number of integrations with external systems, we've consistently seen inconsistent and non-standard behavior.

Because there's no reliable, universal way to detect and redact sensitive content across arbitrary external systems, a full block-level log export would risk exposing sensitive data as a side effect of debugging — which we consider an unacceptable security tradeoff.

Recommended approach:

The right way to solve the underlying problem — visibility into why a production workflow failed — is at the workflow design level, not through raw log export:

1. Handle errors at the block level, not globally. Rather than wrapping large sections of a workflow in a single try-catch, apply targeted try-catch/guard logic around the specific blocks where failures are expected or meaningful. A single catch-all around an entire workflow typically only tells you "something went wrong," which isn't actionable.

2. Add explicit checks after integration calls, especially for external systems known to return ambiguous status codes or embed error conditions inside a "successful" response body. Use Throw to fail the execution with clear, safe diagnostic information, or Exit to complete successfully once the condition has been handled.

3. Assign debug information deliberately. Capture only the specific, safe data points needed to diagnose an issue (e.g., which step failed, a non-sensitive status indicator, a correlation ID) rather than logging entire request/response payloads.

Designing workflows this way ensures that when a failure occurs, the execution output already contains enough safe, relevant information for the responsible team to diagnose the issue — without needing a raw export of every block's execution data, and without the security exposure that would come with it.

As for the ability to export Logs, I would like to ask for a separate idea that requests for that specifically. Thank you.