Skip to main content

Child & Interaction Tickets

A ticket rarely lives in isolation. During its lifecycle it can spawn child tickets for backend work, and — while that backend work is in flight — interaction tickets to keep the customer cared for. This page explains both, and why the AI goes quiet while a ticket is open.

Child Tickets​

A child ticket is a sub-ticket created during a parent ticket's lifecycle to handle one small, well-defined part of the work — an objective — that a human or backend team needs to complete before the AI can continue.

A good way to think about it: the parent ticket is the whole customer request; a child ticket is one specific question or task that has to be answered by a person (often a backend team) before the AI can move forward — for example "confirm whether this order shipped" or "approve this exception."

When a child ticket is created​

While the AI is working a ticket, a workflow can decide the next step must be handled by a human. When that happens, Flowcall:

  • Creates a child ticket carrying the objective — the parameter to fill, an instruction for the agent, an optional hint, and either a free-text answer or a set of selectable options.
  • Routes the child to the right team (often a backend team), based on the objective's tags.
  • Names it after the parent (for example T-1024_c1, T-1024_c2).

If an unresolved child for the same objective already exists, Flowcall reuses it rather than creating a duplicate.

What happens to the parent​

When a child ticket is created, the parent moves to blocked and is unassigned — it's now waiting on the child's answer and can't progress on its own.

Objectives are handled one at a time. If several objectives are lined up, only one child is actively queued or assigned; the rest wait in blocked until it's their turn.

When a child is resolved​

The agent submits the child's response (and an optional resolution). Flowcall then:

  1. Marks the child resolved by agent and copies its answer back onto the parent.
  2. Looks for the next blocked child of the same parent:
    • If one remains, it's promoted to queued and the parent stays blocked.
    • If none remain, the parent is unblocked back to in progress — the answer flows into the AI workflow, the AI resumes the conversation, and the customer is served again.

When a parent ticket is resolved directly, any of its still-open (non-interaction) child tickets are auto-closed.

Sharing a resolution with the customer​

When resolving a child, the agent can choose to share the resolution with the customer — it appears to them as a note — or keep it internal. Backend objectives are usually internal; the AI weaves the answer into its reply.

Why the AI Stops Responding​

When a ticket is open with a human — and especially when a backend child ticket is in progress — the AI stops auto-responding to the customer. This is deliberate: it prevents the AI from talking over a human who is mid-investigation or contradicting an answer the backend team hasn't finished yet.

Practically, the customer's AI is switched to manual while the human handles things. Any messages the customer sends in the meantime are held rather than auto-answered. The AI is re-enabled automatically once the work is resolved (or the blocking child is answered and the parent returns to in progress).

AI auto-replies can also be paused at the account or channel level independently of tickets — see Settings → Channel Access.

Interaction Tickets​

Backend work takes time. A backend team might need hours to confirm something, and while the parent ticket sits blocked, the AI is paused — so a customer who messages in the meantime would otherwise get silence. Interaction tickets exist to handle exactly that situation.

An interaction ticket is created when a customer reaches out while a backend ticket of theirs is open and the AI is paused. It routes that customer interaction to a front-line team so someone can respond, without disturbing the backend work still underway.

When one is created​

An interaction ticket is created when all of the following hold:

  • The customer has an open backend ticket (a ticket on a backend team that isn't itself an interaction ticket).
  • That backend ticket has been waiting at least a configured delay — interaction tickets are meant for the gap when the backend team is taking a while, not for instant replies.
  • The customer sends a message during that window.

Interaction tickets must be enabled for your business, with a delay and a designated interaction team configured.

How it behaves​

  • It's linked to the main ticket (the parent of the backend work, or the backend ticket itself) so the context stays connected.
  • There is at most one open interaction ticket per main ticket — Flowcall won't pile up duplicates if the customer sends several messages.
  • It's routed to the configured interaction team (a front-line team) and assigned like any other ticket.
  • Resolving an interaction ticket does not unblock or resolve the underlying backend work — it only handles the customer's immediate message.
  • When the underlying work finishes (the backend child or the parent is resolved), open interaction tickets are auto-closed.

In short: child tickets push work down to a backend team and block the parent; interaction tickets keep the customer attended to while that backend work runs.

  • Ticket Lifecycle — the statuses these tickets move through.
  • Ticket View — working child and interaction tickets in the ticket panel.
  • Teams & Assignment — backend vs front-line teams, and how each of these tickets is routed.
  • Workflows — where objectives that become child tickets are configured.