What built-in tools are
Built-in tools are actions your Finn can take during a call, as opposed to things it says. You attach them in the workflow editor as Action nodes (see tools-overview for how tools are selected and invoked). They are configured in the dashboard, not registered over the API. If you need something not on this list, write your own with tools-custom.
| Tool | What it does | Prerequisite |
|---|---|---|
| Transfer Call | Hands the live call to a human | A destination number or SIP endpoint |
| End Call | Terminates the call | None |
| Book Calendar | Creates an event on a connected calendar | Google Calendar or Microsoft 365 connected |
| Update CRM | Writes a field to HubSpot, Salesforce, or Pipedrive | That CRM connected |
| Send SMS | Sends a follow-up text | Not yet documented which numbers can originate SMS |
| Webhook | Calls a URL you own and returns the response into the call | An HTTPS endpoint you control |
Transfer Call
Hands the conversation to a real person. The Finn stops talking and the caller is connected.
The common shape is a Decision node feeding a Transfer node, so transfer happens only under a condition you control. From the clinic intake example in the workflow docs, severity 8 or higher routes straight to the on-call doctor rather than continuing the script.
What goes wrong: the destination does not pick up. Nothing in the platform can make a human answer. Design the flow so the Finn has already collected the important information (name, callback number, reason) before the transfer node, so a failed transfer still leaves you a usable record. See tools-transfer for the transfer-specific configuration.
End Call
Terminates the call. Every workflow path should reach an End node.
Use multiple End nodes rather than one shared end. Each End node becomes a separate category in analytics, so "ended with booking", "ended with transfer", and "ended with refusal" show up as distinct outcomes instead of collapsing into a single count. See call-outcomes.
The End node also has a hand off to free-form option. Instead of terminating, the Finn exits the workflow and keeps talking conversationally using its Identity and Knowledge Base for the rest of the call. Use this when the required part of the conversation is done but the caller may still have questions.
Book Calendar
Adds an event to a calendar you connected under Settings → Integrations. Google Calendar and Microsoft Outlook / Microsoft 365 support direct booking.
Availability is enforced by the calendar connection, not by the workflow. When you connect a calendar you set:
| Setting | Effect |
|---|---|
| Working hours | Bookings are only offered inside this window |
| Buffer between events | Minimum gap between consecutive appointments |
| Max events per day | Optional cap |
Calendly and Cal.com behave differently. They do not support direct booking the same way, so the Finn instead says it will send a booking link and an SMS or email goes out with the URL. Callers have to complete the booking themselves afterwards, which means a booked-link call is not a booked appointment. Prefer Google or Outlook if you have the choice.
The Book Calendar action returns data back into the flow. The booked time becomes a variable you can reference, for example {{state.appointment_time}}, and a Book Calendar action can also return {{state.appointment_id}}. Reference it in a later Say node to confirm.
Update CRM
Writes a field back to HubSpot, Salesforce, or Pipedrive. The CRM has to be connected first under Settings → Integrations, including the field mapping step where you tell Finn which CRM property holds the name, the phone, and the country code.
Related but separate: Outcome Sync, enabled during CRM setup, writes every completed call into the CRM automatically. In HubSpot each completed call becomes an engagement and post-call analysis fields become property updates. If Outcome Sync already covers what you need, you do not need an Update CRM node at all.
Send SMS
Sends a follow-up text. This is also the mechanism behind the Calendly/Cal.com booking link.
Webhook (live lookup)
Calls a URL you own during the conversation and puts the response into the call. Use it when the answer lives in your system rather than in Finn.
The pattern: a customer asks about an order, the Finn posts the caller's phone number to your endpoint, your endpoint returns something like { "order_status": "shipped", "tracking": "1Z..." }, and the Finn uses those values in its next reply. The response becomes available as workflow variables.
A minimal endpoint:
from flask import Flask, request, jsonify
app = Flask(__name__)
@app.post("/lookup")
def lookup():
payload = request.get_json()
phone = payload.get("phone_number")
order = ORDERS.get(phone)
if order is None:
return jsonify({"order_status": "not_found"}), 200
return jsonify({
"order_status": order["status"],
"tracking": order["tracking"],
}), 200
Return 200 with a "not found" value rather than a 404. The caller is on the line waiting, and an error response gives the Finn nothing to say. Keep the handler fast for the same reason.
Do not confuse this with outbound event webhooks, which notify your systems after a call. Those are covered in webhooks.
Passing data into tool parameters
Every Action node accepts variables in its parameters, using the same double-brace syntax as Say and Ask nodes. {{contact.name}} comes from the audience row, {{state.severity}} comes from an earlier Ask node.
The most common failure is a name mismatch. If the Ask node saved to severity_score and the Action references {{state.severity}}, the literal text {{state.severity}} reaches the tool. Nothing throws. The names have to match exactly. See agents-variables.
Testing
Test actions before launch. Test on Chat runs a text simulator in the browser and shows each node's inputs and outputs, which is enough to confirm the right variables reach the tool. Test on Call calls your phone and is the only way to confirm a transfer or an SMS actually lands. Do both.