Skip to main content
The trace view shows every detail of a workflow run: each step, its inputs and outputs, decisions made at conditional branches, AI inference calls with prompts and responses, integration calls with payloads, and any side effects. It is the primary surface for debugging and the human-readable projection of the audit chain.

​
Anatomy of a trace

A workflow run trace shows:

​
PHI in traces

Trace view applies your org’s PHI policy. If a step processed PHI, the trace renders the processed (de-identified) version unless you are on a role that has explicit PHI-view access. Raw PHI is never stored in the trace — it is processed through the PHI substrate before the trace record is written.

​
Sandbox vs. production

Same UI, different verb. The distinction is always visible so you know which mode you’re in.

​
Replay

Replay re-runs a past workflow execution with its original trigger payload. Use it to:
  • Reproduce a bug exactly as it occurred
  • Verify a fix against a historical failure case
  • Test a contract change against a real payload from production

​
How to replay

  1. Open the trace for the run you want to replay.
  2. Click Replay.
  3. Confirm: replay runs in sandbox mode by default. You can switch to production if you need to re-trigger real side effects (requires explicit confirmation).
  4. A new run fires. The trace for the new run appears alongside the original. Differences are highlighted.
Replaying in production mode triggers real side effects — real emails sent, real API calls made, real entity records written. Confirm you intend this before proceeding.

​
Trigger simulation

For headless workflows (scheduled, webhook, external event), you can compose and fire a synthetic trigger payload from the test/run console without waiting for a real external event:
  1. Open the test/run console for the workflow.
  2. The system generates a sample trigger payload matching the schema. Edit field values to match your test case.
  3. Click Run.
  4. The workflow fires in sandbox mode. The trace appears immediately.
This is the primary authoring loop for headless workflows — describe, compile, simulate, inspect trace, iterate.

​
Accessing traces

  • From the project overview: recent failures surface in the health rollup with a click-through to the failing run’s trace.
  • From the workflow resource view: a list of recent runs with status, duration, and trigger type. Click any run to open its trace.
  • From the audit log: the trace is the user-facing projection of the run’s audit chain entries. Every event in the trace has a corresponding integrity-anchored audit record.

​
Run history

The test/run console shows recent runs for the workflow with:
  • Status (completed, failed, in-progress)
  • Trigger type and key payload fields
  • Duration
  • Whether side effects were real or sandboxed
Click any run to open its full trace.

​
Compliance use

Traces are durable audit artifacts. Every step, every AI inference call, every side effect, and every data mutation is integrity-anchored per the audit chain architecture. Traces are retained per your org’s compliance retention policy and are exportable for regulatory review. See Compliance & Audit for the full audit chain and export model.