HarkHarkDocs
Theme

Chat flows and the builder

What a resolution flow is, the triggers that start one, and the conversational node types that guide a customer to an answer.

A chat flow is a scripted conversation that runs on a chat widget. You build it visually as a tree of nodes; the widget walks it step by step. Flows resolve common questions without a human, collect the right context before an escalation, and hand off cleanly when a person is needed. The whole tree runs on the server, so the embed never sees your logic.

What starts a flow

Every flow begins at a start node that names its trigger, the event that sets it running:

TriggerFires when
widget_openedA visitor opens the chat widget.
conversation_startedA new conversation begins.
sla_at_riskA conversation's SLA timer enters the at-risk stage.
sla_criticalAn SLA timer becomes critical.
sla_breachedAn SLA timer breaches.
ticket_createdA ticket is created.
mode_changedA conversation changes support mode.
github_issue_openedA linked GitHub issue is opened.

The widget triggers (widget_opened, conversation_started) power customer-facing bots; the rest power automation (see Versioning and automation).

The conversational nodes

These are the nodes that talk to the customer or steer the path:

  • Message: sends text to the customer. Text supports variable substitution, so you can greet someone by the name a lookup found.
  • Question: asks the customer something and saves the answer. The input can be buttons, free text, an email, a number, or a yes/no. Buttons and yes/no branch through their options; text, email, and number continue on a single path and can re-prompt if a required answer is left empty.
  • Condition: branches on collected variables. Each branch holds a set of tests (equals, not equals, contains, greater than, less than, is set, is empty, one of), and the first branch whose tests all hold wins; an otherwise branch catches the rest.
  • Confirm: asks the customer whether their issue is handled and routes on three fixed answers (resolved, partially resolved, not resolved). On resolved it can collect a built-in 1 to 5 satisfaction rating.
  • Delay: pauses the run for a set time, then continues. The run is parked durably and resumed later, so a flow can wait minutes or days (up to 30) without holding anything open.
  • Split: sends visitors down different branches by weight, deterministically. The same visitor always lands in the same branch, which is what makes A/B experiments reproducible (see experiments under Versioning and automation).
  • Subflow: runs another published flow inline and returns, so you can reuse a common sequence (like identity collection) across many flows.
  • Handoff: ends the scripted run and moves the conversation to human support, optionally to a specific team and with an internal note for the receiving agent.
  • End: finishes the run with a structured outcome (resolved, partially resolved, escalated, failed, abandoned, or redirected), optionally closing the conversation and optionally asking a satisfaction question first.

Variables

As a flow runs it collects variables (a question's answer, a lookup's result, an AI classification). Later nodes read them: a message can substitute one into its text, and a condition can branch on one. This is how a flow carries what it learns from one step to the next.