VoxaLinkSupport
09Chapter 9 of 10

Testing & publishing

Drafts, publishing, what gets validated, and how to test an agent before trusting it with real callers.

Read time~ 3 min
Sections6
UpdatedJuly 17, 2026

Every change to an agent — its Assistant, Knowledge, Calendars, or flow — is saved as a draft first. Nothing a caller experiences changes until you publish.

Why drafts are safe to experiment with

A live call always runs whatever version was published most recently, never the draft. You can edit an agent's instructions, add knowledge, or restructure its flow in the middle of the day with zero risk to a call already in progress — the change only takes effect the next time you publish. If a published change doesn't work out, you can roll back to the previous published version.

Testing an agent

There's no separate sandbox or preview mode — testing means publishing the agent, then placing a real call through it. For an inbound agent, that's simply calling the number it's attached to. For an agent you're building for outbound use, publish it and use the manual "Place a call" option to queue a single test call to a number of your choosing, without needing a full campaign.

<!-- SCREENSHOT: voice-agent-test-call.png -->

Listen for: does the greeting sound right, does it answer correctly from your Knowledge, does a booking step actually check the calendar, and does it hand off cleanly when it should.

What publishing checks

Publishing runs a full validation pass and will refuse to go live if anything would leave a caller stuck. Common reasons a publish is blocked:

  • No fallback destination — every agent needs somewhere to send a call it can't handle.
  • No human-handoff path — there must be a way for the agent to reach a person.
  • A booking step's calendar isn't connected or writable — reconnect it under Settings first.
  • A texting step is used, but SMS isn't enabled for the tenant or the sending number can't send.
  • Recording mode not set explicitly — you must choose a recording policy rather than leave it as "default."
  • Outbound agents specifically need recipient verification turned on before they can be attached to a campaign.

The error message names the specific problem — fix that one thing and publish again.

What happens on publish

Publishing compiles the current draft into a runtime version and attaches it live:

  • For an inbound agent, that means any call routed to its account number (directly, or via an auto attendant pointing at it) now reaches this version.
  • For an outbound agent, it becomes usable in campaigns and manual test calls.

Disabling an agent

Disabling an agent stops it being scheduled into new outbound campaigns. It doesn't automatically detach an inbound agent from whatever's routing calls to it — if you want to fully take an agent offline, also update whatever points to it (an auto attendant menu option, a DID, and so on).

Everyday tasks

  • Try a change before trusting it with real callers → publish, then place a manual test call.
  • Undo a change that made things worse → roll back to the previous published version.
  • Find out why publish won't go through → read the error message — it names the exact missing requirement.
  • Take an agent fully offline → disable it, and update anything that currently routes calls to it.