Flows advanced configuration

The following table lists all advanced configuration parameters supported by Flows and references to relevant documentation sections.

Parameter name	Description
`active_listening`	Active listening mode
`error_message`	Message to be played if LLM response couldn't be generated due to some error. Refer to Error message for detailed description of similar AI Agent functionality.
`empty_llm_response`	Empty LLM responses
`gemini_api`	Selecting the model API — applied per conversation node
`incomplete_turn`	Incomplete turn detection — applied to conversation nodes
`init_conditions`	Init conditions
`llm_logs`	Detailed LLM logs for troubleshooting
`max_transitions`	Maximum transitions between nodes
`max_turns_message`	Error message
`no_user_input_repeat`	Handling user inactivity
`openai_api`	Selecting the model API — applied per conversation node (flows use the stateless Responses API)
`post_call_analysis`	Post call analysis
`prompt_log`	Logging the agent prompt — the flow prompt is logged once: at the beginning of the conversation, or when the flow is handed the conversation
`reasoning_effort`	Reasoning effort
`remove_symbols`	STT error correction configuration
`replace_words`
`start_delay`	Delaying the conversation start
`tool_certs`	Custom tool certificates
`tool_logs`	Detailed tool call logs
`tts_stream`	TTS streaming

Maximum transitions between nodes

The maximum_transitions advanced configuration parameter configures maximum number of transitions between nodes. It may be used to limit total conversation length and prevents endless loops.

Parameter	Type	Description
`maximum_transitions`	int	Maximum number of transitions allowed in the flow.

Example

{
    "maximum_transitions": 30
}

Handling user inactivity

When user remains silent, NO-USER-INPUT events are generated, as described in Speech events. You can configure flow to repeat the last response upon one of these events via the no_user_input_repeat advanced configuration parameter.

Specify a list of numeric NO-USER-INPUT event occurrences that should trigger the repeat. For example, the following configures the flow to repeat last response upon the first inactivity event – NO-USER-INPUT-1:

{
  "no_user_input_repeat": [ 1 ]
}

If you specify multiple indexes, e.g. [1, 2], response will be repeated upon multiple inactivity event occurrences (NO-USER-INPUT-1 and NO-USER-INPUT-2 in the above example).

Parameter	Type	Description
`no_user_input_repeat`	list[int]	NO-USER-INPUT event occurrences which trigger repeating the last LLM response.

If you want to end or transfer the call upon user inactivity, create corresponding global node and use the following logical statement in global condition:

(user_utterance == "NO-USER-INPUT-2")

The above example uses second inactivity event (NO-USER-INPUT-2) as a trigger. Adjust the number based on your needs.

Delaying the conversation start

The start_delay advanced configuration parameter configures delay in milliseconds before the flow starts the conversation. It may be used to make sure the first response isn't played before the call is fully established.

Parameter	Type	Description
`start_delay`	int	Delay in milliseconds before the conversation starts.

Example

{
    "start_delay": 1500
}

This is the Flow counterpart of the AI Agent welcome_message_delay parameter.