Skip to main content
Version: 0.9.19

Review a conversation and its result

Use this task after an approved test or when investigating an unexpected interaction. Find the correct conversation, compare its actual behavior with the expected result, and collect the identifiers needed for follow-up. Opening a record or seeing a recording indicator alone does not establish that the interaction succeeded.

Availability: The Conversations list and full detail page require an eligible account in the selected team: Team Members and Team Admins, or a platform administrator. These pages use a stricter UI permission than some other read-only surfaces; a Team Viewer or platform Superviewer should not assume that broader read access opens this screen. If access is denied, ask the team administrator for an authorized review. A shared detail URL does not grant access to its data.

The evidence available depends on what the runtime recorded. Audio requires a retained, processed full-call audio output and accessible recording storage. Debug data depends on the observability connection, captured telemetry and retention. QA and Actions tabs appear only when the conversation contains their corresponding data. A missing tab is not, by itself, a failed call or an instruction to enable a module.

Prepare the review​

Have the application/team, approximate test time, intended endpoint and expected response ready. If the test provides a conversation link or call ID, keep it. For a flow change, also record the version you intended to publish using Change an application and verify its published flow.

1. Find the right conversation​

  1. Open Conversations and select the application in the app selector.
  2. Choose the call matching your test time. The list is newest first and loads more entries as you scroll. Use the caller, duration and available status information as supporting clues; caller data may be absent or redacted.
  3. Open the record and verify its header and Overview identifiers. Match the call ID to the test result when one is available. Do not select a neighboring call merely because its time looks similar.

Changing the app selection clears the selected conversation. The list URL can retain the application and selected record; the detail's maximize control opens /conversations/<conversation-id> for an authorized colleague. Previous/next controls help compare calls, but recheck the record after navigating.

The app selector filters the call list. Search and event filters within a detail tab filter that conversation's evidence; they do not search all calls in every application.

2. Start with Overview, then follow the evidence​

Overview is the initial tab. Read the summary if present, check the interaction counts and error count, and note the call ID, trace ID and flow information. Treat a generated summary as a starting point and verify the relevant events yourself. Flow information helps correlation; it does not independently prove that every runtime component used the intended published configuration.

Tab or viewUse it to answerLimit to keep in mind
TimelineWhat was said, which nodes were entered, and which transitions, actions, keypad events or errors were recorded?It is assembled from recorded conversation data and selected system events, not a complete network trace or an audio transcript guarantee.
Flow runWhich node visits and transitions were recorded, and where was time spent?It uses node history; a missing history does not prove no execution occurred.
TokensWhat model/token and speech usage was recorded for the interaction?Missing usage is not proof of zero consumption; use the recorded data for this call rather than treating it as a provider invoice.
Actions, when presentWhich recorded actions were invoked and what results/details are available?Only appears when action events exist. It is not a list of every tool that could have been called.
QA, when presentWhat score and evaluation details were stored?Only appears when score or score details exist. Absence does not establish that the call failed.
Debug → Logs / Span tree / SIP ladderWhat runtime, trace or signaling evidence helps explain the result?Availability, capture and retention differ from the persisted conversation and recording data.

3. Inspect the interaction and errors​

In Timeline, use Search for a distinctive word or event and use the event-kind checkboxes to narrow the view. Clear the search and restore relevant kinds before concluding an event is missing. Node exit events are hidden initially; enable them when investigating how a node ended.

Compare the recorded user input, response and next step with the expected result. If the flow made a wrong transition or stopped unexpectedly, use Flow run to inspect the associated node visits, timings and transition target. Examine recorded errors near that point. A displayed transcript may be incomplete or redacted; do not interpret a redacted value as the user's actual words.

Search the logs of a call​

Open Debug → Logs when the Timeline does not explain the result. The tab loads up to 2,000 log rows for this call, oldest first, and its title shows how many rows are listed.

Type into Search to narrow the rows. The search works like this:

  • It covers the loaded rows of this call only. It does not search other calls, and it does not ask the log server again.
  • It ignores upper and lower case and matches part of a word. transf finds transfer.
  • When you type several words, a row must contain every word.
  • It looks in the summary, message, level, type, service and component, in the raw log text, and in the attributes of the row.

Attributes are the structured fields that a service attaches to a log row. You see them under Attributes when you open a row. Search includes them, so you can find a value that the row itself does not show. For example, a call log can include a call identifier in its attributes. Searching for that identifier finds related rows.

What you look forWhat to type
A transfer requesttransfer, or the target number
A request from an integrationThe event name or a value from its body
Errors from one serviceThe service name and error

Use the filter button to limit rows by Type, Service, Component or Level, and the column button to show or hide columns. Open a row to read the full message, the attributes and the raw text. Check the rows before and after it; one error message alone rarely explains a result.

Three limits apply:

  • Long attributes: search reads the first 20,000 characters of the attributes of a row. A value further down a very large payload is not found. Open the row and read it there.
  • SIP captures: these rows are hidden until you turn on Show SIP capture logs. While they are hidden, search does not match them. For signaling, the SIP ladder is usually the better view.
  • Retention: when the call is older than the log server keeps data, the tab shows a retention message and no rows. The conversation record itself stays available. From 0.9.19, the platform stores a copy of the Span tree and SIP ladder with each voice conversation shortly after the call ends, so those two views stay available after the log server has discarded the data. Search in Logs still needs the log server.

If search finds nothing, clear the search box and the filters, then check the row count in the title before you conclude that an event is missing. For trace correlation, retention and the handling of sensitive data, use Logs and diagnostics.

For a telephone routing, hangup or signaling problem, continue with SIP diagnostics, using the call/trace identifiers and time. A missing SIP ladder for a browser-text interaction is not evidence of failure.

Transfers, hangups and keypad input​

When a transfer was recorded for the call, Overview shows a Transfers section with each target, its mode and status, and its duration. Keypad input has its own event kind in Timeline. On the SIP ladder, a keypad row shows the digits it carried, for example DTMF 1; when the deployment does not log personal data (see PII logging), the digits are masked as *. A hangup has no event kind of its own: look for the last node entered, its exit and any recorded error, then confirm how the call ended in Debug → SIP ladder when a capture is available.

These views show what was recorded for this call. To see what the flow was configured to do, open the node in Flow Designer and compare its fields with the Transfer, End and DTMF references. For the cause value and SIP headers sent with a hangup or transfer, use the SIP termination reference.

Review a QA result​

Open QA when the conversation has a stored score or score details. The tab is data-dependent: a missing tab does not prove scoring is disabled, that a job failed or that the call was unsuccessful. Access to the conversation follows the account/team requirements at the start of this guide; seeing an aggregate widget does not grant access to the underlying conversation.

  1. Read Overall alongside the summary and the four dimensions: Task completion, Communication quality, Efficiency and Error handling. Expand your investigation into Timeline/Flow run rather than accepting the generated explanation without evidence.
  2. Read Caller satisfaction separately. This score is normalized to an integer from 0 to 10 by the scoring worker; it is not the same scale as the overall/dimension scores. A displayed hard-failure label identifies the scorer's reported issue, not an independently verified network diagnosis.
  3. Compare Highlights and Improvements with the actual interaction and your intended outcome. Missing reasoning, lists or score fields can mean incomplete retained evaluation data; an em dash is not a zero score.
  4. Use the raw JSON view when an authorized investigator needs the stored qaStatus, qaScore and details. Copy JSON copies that data to the clipboard; it can contain conversation-derived information. Share only the necessary redacted evidence. The view switch is a presentation preference, not an edit or a scoring action.

The overall/dimension display uses green at 80 or above, amber at 60–79 and red below 60, with no score shown as neutral. These are UI thresholds, not service guarantees. The worker checks for an overall numeric score and the expected top-level result shape, but does not clamp every overall/dimension score to 0–100; investigate an implausible value instead of treating its color as validation.

If an opened QA tab reports pending, failed or no details, note the state and ask the operator to inspect the scoring job and prerequisites. The worker can skip records without a transcript or without permitted platform/team/app/plan scoring. An already completed record is skipped by the normal scoring handler; reopening this tab does not request a re-score. This detail view has no manual score-edit or re-score button. Use Background jobs for operator diagnosis and QA configuration for future scoring behavior.

When comparing against the dashboard, remember that its caller-satisfaction average excludes hard failures and omits some apps without an eligible average sample. Keep the individual result, sample/exclusion rules and observed application outcome separate.

4. Check retained audio separately​

When full-call audio is available, use the header's recording controls to select and play the retained recording. Compare what you hear with the event sequence; text events alone do not prove audible output reached the caller.

Recording state or symptomInterpretation and next step
PROCESSINGUpload or processing is pending. The detail refreshes while this status remains; if it persists, ask the operator to investigate.
AVAILABLE but no playable audioCheck which outputs were selected and whether the audio lookup succeeds. A transcript-only recording has no full-call audio player.
FAILEDInvestigate recording processing/storage; this status alone does not describe whether the conversation itself succeeded.
No recording sectionDo not infer that the call did not happen. Capture selection, frequency, available artifacts and storage access can differ.

The Timeline text and a retained transcript object are separate evidence sources. Changing logging redaction does not necessarily change recording retention. See Choose what a call recording retains for future capture choices and Recording diagnostics for a missing artifact.

Do not use Delete recordings as a diagnostic step: it is a destructive action, not a refresh control. Review does not require changing recording or privacy settings.

5. Resolve a missing result and finish the review​

If the result is missing or incomplete, distinguish these cases before repeating the test:

  • No conversation found: confirm the team, app, endpoint and test time. A just-ended test may still be waiting for its conversation record. Reopen the result after processing; if it remains absent, give the operator the call ID and time rather than assuming an unrelated row is the result.
  • Detail cannot be loaded: the record may be unavailable or outside your access. Ask an authorized team member to check the ID; a URL is not an access credential.
  • Empty Timeline or Flow run: clear local filters and check which data was retained. Ask the operator to correlate the call with runtime evidence if the expected events are still missing.
  • Empty or unavailable Debug: inspect the configuration/retention message and involve the observability operator. The persisted conversation can outlive its searchable telemetry.
  • Wrong behavior after a flow change: confirm the endpoint, publication and runtime synchronization before changing the flow again. Use the application change procedure for deliberate recovery.

Record the outcome, conversation URL/ID, call and trace IDs when present, time, endpoint, expected versus actual behavior, and the relevant error. Share only necessary evidence through an authorized channel; raw logs, transcripts and signaling can contain sensitive data.

The review is complete when you can identify the tested interaction and support its outcome with the available evidence—or state precisely which evidence is missing and who must investigate it. A visible success indicator does not replace that comparison.