> ## Documentation Index
> Fetch the complete documentation index at: https://docs.assistable.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Run a tool from a flow

> Configure a reusable action, supply its inputs, and verify the external result.

A **Tool** node runs an action from the flow's tool kit. Use it for a reusable integration; use a [Request node](/v3/guides/flows/api-requests) when you need to configure an HTTP request directly.

## Before you start

Have the integration ready and decide how you will check the result. For a CRM update, that means inspecting the intended contact afterward; for a booking, it means checking the appointment record. Use a test account or reversible action while building.

## Configure the node

1. Open the flow's tool kit and add or select the required tool.
2. Add a Tool node and choose that tool.
3. Collect the values the tool requires before reaching this node. The model fills tool arguments from the conversation and available variables; inspect the actual input in the test result.
4. Connect the node to the next conversational step.
5. Keep the action synchronous when the next step needs its result.

Missing inputs can cause a tool call to fail or require additional model-generated arguments. Collect and check required information before the action; do not rely on the assistant to infer account IDs or booking details.

## Explain a wait

**Speak During Execution** can provide a short message while work runs. Use Static for fixed text such as “Let me check that”, or Prompt for generated filler. Keep filler neutral: “Your booking is confirmed” is inappropriate before the booking result is known.

## Background actions

An asynchronous tool may return an acknowledgement before the external action finishes. A later callback requires support from the receiving service and the configured callback path. Do not use that acknowledgement as proof that an email was delivered or a CRM record was updated.

If downstream logic depends on the output, leave **Async** off. Avoid retrying a write until you have checked whether the first attempt already completed.

## Verify the action

Run a successful case and a failure case. Check the actual external record, not only the assistant's wording. Confirm that failures lead to an honest recovery message. Resetting the conversation does not undo a completed external action.

## Tool node settings

| Control | Choices and behavior |
| - | - |
| Tool | Select a tool available to this subaccount. **Create / manage tools** opens tool configuration; required inputs and authentication belong to that tool. |
| Async | Off by default. Off uses the normal synchronous tool path. On sends a background request through the tool’s configured endpoint; use only with an endpoint designed for that workflow. |
| Wait for Result | Displayed on by default, but currently does not control execution. Use **Async** to choose background behavior. |
| Speak During Execution | On for a newly added Tool node. Provides filler while work runs; it is not a success message. |
| Static Text / AI Generated | Static uses your filler text. AI Generated uses your filler instruction; new nodes use AI Generated. Both can reference known variables. |
| Outgoing conditions / otherwise | Select the next connected path based on the tool result. Wire a recovery destination for failures. |

The current node settings do not provide a parameter-mapping editor. Where an imported flow already contains explicit mappings, those mappings take precedence; otherwise the model fills missing arguments. If an exact request field/value mapping is essential, use an [API Call node](/v3/guides/flows/api-requests).

## Outputs and background callbacks

A completed function node stores its result as text in `{{_last_function_result}}`. An error can populate `{{_last_function_error}}`; an old error is not a reliable status for a later successful call. Both are transient and are cleared when a Conversation step consumes tool history. Extract the values you need and verify the current tool result before branching.

Background HTTP tools need a receiver that supports the supplied callback contract. When callback support is configured, the JSON request includes `_return_url` and `_async`; the signed callback URL expires after 30 minutes. A session and server callback configuration are required. Do not enable Async for a tool merely because it appears in the selector: background execution does not use every part of the normal synchronous tool path.

A pending result confirms submission only. Keep subsequent conversation independent of the final outcome until the callback or external system confirms it.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.