Skip to main content
DialNexa troubleshooting starts by finding the object that owns the problem, then checking evidence. Most issues belong to one of these areas: agent version, provider stack, phone number routing, launch data, workflow graph, integration credentials, or monitoring evidence.
Debugging gets faster when every theory has a call id, version number, or workflow lead id attached.

DialNexa Troubleshooting By Symptom

Provider-Specific Debugging

General Debugging Routine

1

Find the exact record

Use call id, batch id, workflow lead id, agent version, or webhook delivery id.
2

Read the evidence

Open detail views before changing settings.
3

Trace back one layer

Move from call to route, route to agent version, workflow node to integration, or transcript to transcriber.
4

Change one thing

Make a focused draft edit.
5

Retest and compare

Use the same scenario and compare recording, transcript, status, invocation, and extracted fields.

Common Root Causes

Phone numbers, batches, and workflows can still point at an old version.
Prompt placeholders need launch values or defaults. Check CSV columns, API payload, workflow lead variables, and fallback values.
Batch and workflow calls require an outbound number with a published agent version.
A Hinglish agent on an English-only transcriber, a voice that does not match the language, or a slow action inside a live call can all look like prompt bugs.
Validate or reconnect the integration before editing workflows or agent functions.
Check secret rotation, HTTPS receiver behavior, response codes, and retry handling.

Call Detail Page

Start with evidence.

Voice AI Overview

Understand provider layers.

Agent Versions

Check live version.

Workflow Lead History

Debug workflow paths.