Skip to main content

​
What are During-call Flows?

A during-call flow is a workflow the agent can run while it’s talking to the user, as if it were a tool. Where an integration calls a single endpoint, a during-call flow runs a full multi-step workflow — and can return the result to the conversation. Use one when a single API call isn’t enough:
  • Look up a customer, then check their open orders, then format the combined result
  • Query several systems and merge the answers
  • Make a booking that needs several APIs in sequence
  • Branch on a response before returning data to the agent
During-call flows run during the conversation. Compare with pre-call flows (before the agent greets) and post-call flows (after the call ends).

​
How it works

1

The agent decides to act

Mid-conversation, the agent recognizes it needs to do something — check availability, look up an account — based on the function description you wrote.
2

The flow runs

The agent extracts the parameters from the conversation and the Function Call trigger fires, running the workflow.
3

The agent continues

The agent waits for the result and uses it to keep talking.

​
Build a During-call Flow

1

Create a workflow

From the Workflows section, create a new workflow (from scratch or a template). See Creating Workflows.
2

Select the Function Call trigger

Choose the Diga piece and select the Function Call trigger. The agent will treat this flow as a tool it can invoke.
3

Configure the trigger

Define how and when the agent uses the flow:
  • Function description — when the agent should call it, in natural language
  • Parameters — what the agent should extract from the conversation (and whether each is extracted by the AI or taken from a dynamic variable)
  • User confirmation — whether the agent confirms before running
See The Diga Piece for the full field reference.
4

Add your actions

Add the steps the flow performs — HTTP requests, database queries, other pieces — using the parameters the agent extracts.
5

Return the result

End the flow with the Diga Return Response action so the agent receives the data and can continue the conversation.
The flow must end with Return Response, and respond within 60 seconds. Otherwise the agent receives an error and continues without the data.
6

Publish and enable

Publish the workflow and make sure it’s enabled. Then assign it to an agent (see below).

​
Parameters

Parameters are the data the agent passes to the flow when it runs. For each parameter you define a name, a data type, whether it’s required, and — importantly — a Value Source that decides where its value comes from:
  • Extracted by AI (default): the agent pulls the value from the conversation, using the parameter’s description to know what to look for.
  • Dynamic Variable: the value comes from a dynamic variable on the call instead of being extracted.

​
Filling parameters from dynamic variables

Often you already have a value — passed in via the API, set as an agent default, or produced by a pre-call flow — and you don’t want the agent to ask for it again (or risk getting it wrong). For those parameters, set the Value Source to Dynamic Variable.

​
How to set it up

1

Add or edit a parameter

In the Function Call trigger, open the parameter you want to fill automatically.
2

Set Value Source to Dynamic Variable

Change Value Source from Extracted by AI to Dynamic Variable. The description field is replaced by a Dynamic Variable Name field.
3

Enter the variable name

Type the variable name without braces — for example reservation_id, not {{reservation_id}}.

​
What happens at call time

  • The parameter is removed from what the agent has to work out — it’s never asked for it and can’t fill it incorrectly.
  • When the flow runs, Diga fills that parameter with the current value of the matching dynamic variable on the call and sends it in the workflow payload.
  • Parameters left as Extracted by AI keep working as usual, side by side with the dynamic ones.
The variable must actually exist on the call. Make sure it’s provided by the API, an agent default value, or a pre-call flow — if it’s missing, the parameter is sent empty.

​
Example

A “Modify reservation” flow where the reservation ID is already known from a pre-call lookup, so only the rest is left to the agent: The caller just says “I’d like to cancel my reservation.” The agent extracts action = cancel, Diga injects reservation_id from the dynamic variable, and the flow receives all three values.
Parameters you fill this way also show up in the agent’s dynamic variables panel, where you can give them a test value to try the flow before going live. See Dynamic Variables.

​
Assign During-call Flows to an Agent

Open the agent and go to its Workflows section. Add the during-call flow there. Each flow shows a During call badge.You can assign multiple during-call flows to the same agent — each becomes a tool the agent can choose to use, based on the function description.
Like other flows, during-call flows are assigned per agent version. The flow must be published and enabled before it will run.

​
When the caller interrupts a running flow

Real callers don’t wait politely: they add details or change their mind while a flow is still executing. Diga handles this for you:
  • The execution is never cancelled. Once a flow has been triggered it runs to completion — cancelling it locally wouldn’t undo a booking already being created in your systems.
  • The agent stays informed. It’s told immediately that the flow is still running (so it won’t call it again), and it receives the real outcome as soon as the flow finishes — success or failure.
  • The agent acknowledges what already happened. If the caller changed their mind mid-execution, the agent says out loud what was already done before adjusting, instead of pretending nothing happened or silently duplicating the action.
  • A revised request runs as a new execution. If the caller corrects a detail while the flow runs (“actually, make it 8 instead”), the agent runs the flow again with the corrected values. It never claims a change is done unless an execution actually did it.
  • The agent finishes its sentence first. A result that lands while the agent is talking is delivered at the next pause, never by cutting the agent off mid-sentence.
This behavior is built in — you don’t need to prompt for it. What you control is what the agent can honestly offer next:
Back every promise in your prompt with a flow. The built-in behavior never claims an action the agent cannot perform: if the caller wants to change an appointment and the agent only has a create flow, it will say plainly that the previous appointment still exists and needs handling — it won’t pretend to cancel it. If rescheduling or cancelling matters for your use case, build those flows and assign them too. If you deliberately don’t, tell the agent in your prompt what to do instead (for example, “if the caller wants to change a booking, take note so the team handles it”).
Write your Return Response message as something the agent could say aloud, in your callers’ language. The agent builds its reply from it — “Cita creada para el 25 de agosto a las 10:00” produces a far more natural answer than a raw status in English.

​
If the flow fails while the caller is talking

What the agent tells the caller depends on what the failure proves:
  • The request was rejected (the endpoint answered with a client error such as 400 or 404, so it never ran): the agent knows nothing was saved, says so, and is free to try again with corrected details.
  • The outcome is unknown (the flow timed out, failed with a server error such as 500, or the connection dropped): the flow may have completed before the error, so the agent claims neither that it worked nor that it failed. It tells the caller it couldn’t confirm the action and that it will be checked, and it does not run the flow again, since a repeat could create a duplicate.
If your flow detects a problem, end it with a Return Response that says so in plain words instead of letting it error out. A crash or a timeout leaves the agent unable to tell whether anything happened; an explicit response lets it tell the caller exactly what’s going on.

​
Common use cases

The agent asks for a date, runs the flow to query your calendar, and reads back the available slots.
Pull a customer’s details and recent activity from one or more systems, merge them, and return a clean summary the agent can use.
Run the several API calls a reservation needs in sequence, then confirm the result back to the user.
Create a ticket in your system, then confirm to the user that it’s been logged.

​
Next Steps

The Diga piece

Full reference for the Function Call trigger and Return Response action.

Pre-call flows

Prepare and personalize each call before the agent greets.

Integrations

Compare during-call flows with single-endpoint integrations.

Assign to agents

Connect your workflows with agents so they execute.