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:
| Element | What you see |
|---|
| Run metadata | Run ID, trigger type and payload, start time, duration, status (completed / failed / in-progress) |
| Step-by-step execution | Each step in order: type, inputs, outputs, duration |
| AI inference steps | Model, prompt sent (with substituted values), response received, token usage, confidence scores |
| Integration steps | Outbound call payload, response received, latency |
| Conditional branches | Which branch was taken and why (the evaluated condition and its values) |
| Data-change events | Which entity records were written and what changed |
| Side-effect markers | In production: “sent email to [email protected].” In sandbox: “would have sent email to [email protected].” |
| Errors and retries | Error details, retry count, final disposition |
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
| Mode | Side-effect markers | Integration calls |
|---|
| Sandbox | ”would have done X” | Edge-sandboxed — no real calls |
| Production | ”did do X” | Real calls to external systems |
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
- Open the trace for the run you want to replay.
- Click Replay.
- 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).
- 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:
- Open the test/run console for the workflow.
- The system generates a sample trigger payload matching the schema. Edit field values to match your test case.
- Click Run.
- 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. 
