What changes when you save
Editing a Finn is done in the dashboard: View All Finn → pick the Finn → Edit. Every field in the Create Finn wizard is editable after the fact, including identity text, guardrails, voice, knowledge base, tasks, and post-call analysis fields. There is a Save button in the top-right of every tab, and saving does nothing except persist your work. It does not restart deployments, requeue contacts, or interrupt anything.
The rule that governs everything else on this page:
Changes apply to new calls. Calls already in flight finish under the configuration they started with.
A call picks up its configuration once, at the moment it starts. Nothing you change mid-call reaches that call. A caller who is thirty seconds into a booking flow will not have the prompt swapped underneath them.
What that means per field
| What you change | Effect on in-flight calls | Effect on the next call |
|---|---|---|
| Identity text, style and guardrails, response guidelines | None | Applies |
| Welcome message (dynamic or defined) | None. The opener already played. | Applies |
| Voice, TTS service | None. Voice stays consistent for the whole call. | Applies |
| Language, STT service, custom vocabulary | None | Applies |
| LLM service | None | Applies |
| Knowledge base sources | Not settled. Retrieval happens per lookup, so a call may or may not see freshly indexed content depending on when the lookup fires. Treat mid-call knowledge base edits as unpredictable. | Applies once indexing completes |
Call settings (max_idle_duration, limit_call_duration, voicemail_detection, handoff_number) | None | Applies |
| Post-call analysis fields | The analysis pass runs after the call ends, so a call in flight when you edit may be scored against the new field set | Applies |
Tasks (finn_tasks) | None for tasks already dispatched | Applies |
The post-call analysis row is the one that surprises people. Extraction is a separate LLM pass over the transcript, not something the call carries with it. If you add or rename a field while a deployment is running, your analytics for that deployment will have a ragged boundary: earlier calls scored on the old schema, later calls on the new one. Rename fields between deployments, not during.
Deployments do not re-read on their own
A deployment binds a Finn, an audience, a phone number, and a schedule (see deployments for the launcher, and concurrency for pacing). Editing the Finn does not pause the deployment, does not reset retry counters, and does not re-dial anyone who already completed.
Retries are the sharp edge. A contact who got no-answer before your edit and gets retried after it is called by the new configuration. The same contact, same deployment, two different agents. If you are changing anything a caller would notice, pause the deployment first. Pausing stops new dialing, lets active calls finish, and costs nothing. Resume after you have tested.
If a Finn is running several deployments at once, an edit hits all of them. There is no per-deployment configuration override. To run two variants side by side, duplicate the Finn and point one deployment at each.
Version history and rollback
The platform keeps a history of Finn configurations. Find it at View All Finn → pick the Finn → History. From there you can roll back to an earlier configuration if a change degrades performance.
Rollback behaves like any other edit. It applies to new calls and does not reach in-flight calls or already-completed ones. It does not revert deployments, audiences, phone number assignments, or the analytics already recorded under the old configuration.
The version history is a dashboard feature. There is no documented API for listing or restoring versions. If you need programmatic control over agent configuration, see api-finns for what is exposed.
Details not yet settled in this documentation: how many versions are retained, whether versions can be labeled or annotated, and whether rollback itself creates a new history entry. Do not build a process that depends on a specific retention depth until that is confirmed.
A safe edit loop
- Pause any live deployment using the Finn.
- Make the edit and save.
- Test with Test on Chat for fast iteration on wording, then Test on Call for anything touching voice, latency, or interruption handling. See agents-testing.
- Check the edge cases the change could affect: a confused caller, a hostile caller, a caller who goes off-topic.
- Resume the deployment.
- Watch the first several calls in the live call table and open the transcripts.
If the change makes things worse, roll back from History and re-test. Do not stack a second fix on top of an unverified first one, because the version history will not tell you which of the two caused the regression.