The CRM-to-Voice AI Workflow, Explained Without the Jargon

Connecting a CRM to an AI voice agent comes down to four handoffs. The CRM decides who gets called. The call request carries what the agent needs to know. The agent has the conversation. The results land back on the same CRM record. Most integration confusion comes from blurring those four together, or from not knowing which system owns each one.

This guide walks through the sequence using a HubSpot workflow as the example, then shows the same loop for any CRM that can send a webhook.

What are the four stages of a CRM-to-voice AI workflow?

Trigger, context, conversation and writeback:

1. Trigger. A CRM event (a form fill, a deal stage change, a date reached) starts a workflow that asks the voice platform to place a call.
2. Context. The call request carries data from the CRM record, so the agent starts the call already knowing the contact's name and situation.
3. Conversation. The agent talks, and can read or update CRM records while it does.
4. Writeback. After the call, a summary, structured outcome fields, the transcript and the recording are attached to the CRM record, and the CRM workflow decides what happens next.

What actually triggers the AI call from the CRM?

A CRM workflow triggers the call in one of two ways: a native workflow action, or a webhook that your own service turns into an API call.

Native action (HubSpot). The Retell AI app in the HubSpot Marketplace adds a Make a Phone Call action to HubSpot workflows. Start from a trigger you already use: a form submission, a new record, a deal stage change, or a date property such as an appointment date. Add a "Phone number is known" condition so contacts without a number never enroll. Then fill in three fields on the action: From (the Retell agent and phone number), To (the contact's phone token) and, optionally, Dynamic Variables as JSON. The workflow pauses until the call finishes.

Webhook plus API (any CRM). If your CRM can send a webhook from a workflow, point it at a small service you own. That service calls Retell's Create Phone Call API with four things: from_number, to_number, the context fields in retell_llm_dynamic_variables, and the CRM record ID in metadata. Retell stores metadata with the call and returns it in the call object on later webhooks, which is how the result finds its way back to the right record.

Lists instead of events. For a campaign against a segment rather than a single event, export the list and run it as a batch call: a CSV with a phone number column, where every extra column becomes a variable the agent can use.

Two prerequisites apply on every path. The calling number needs an outbound agent bound to it, and the numbers you dial need to be valid E.164 (for example, +14155550123).

How does the agent know who it's calling?

Through dynamic variables: named values such as {{first_name}} or {{deal_stage}} that Retell fills in before the agent speaks. They come from three places:

• The call request. Whatever the HubSpot action's JSON or your API call passes in retell_llm_dynamic_variables.
• Synced contact fields. If you run Retell's native CRM contact sync, a call whose number matches a synced contact gets that contact's mapped fields as variables automatically.
• A pre-call lookup. A pre-call function on the agent's Workflow page can search the CRM for the number and map fields from the response into variables. On outbound calls it runs before Retell dials, so the contact never hears the lookup.

When the same name comes from more than one source, the request value beats the synced contact field, and anything the agent collects during the call beats both.

Three rules prevent most cases of an agent reading a placeholder out loud:

• Send every value as a string, so "42" and "true", not 42 and true.
• Flatten objects. {{client.name}} won't resolve; send client_name instead.
• Set agent-level defaults. A variable with no value stays in its raw {{braces}} form in the prompt.

What happens during the call?

The agent runs the conversation from its prompt and variables, and can act on the CRM mid-call if you give it tools.

With HubSpot connected through Retell's native integration, the agent can use tools such as Search Contact, List Contact Deals, Update Deal, Update Contact and Create Task while it's talking. It can correct an email address the contact just gave, or create the follow-up task the contact agreed to. For a CRM without a native integration, a custom function does the same job by calling your own API mid-call.

Plan for two behaviors. If a CRM tool call fails or times out, the conversation carries on, so the prompt should tell the agent what to say when a lookup comes back empty. And when an outbound call reaches voicemail instead of a person, the agent can hang up or leave a message, depending on how you configure it, and the call is flagged with in_voicemail. That flag matters at writeback.

How do call results get back into the CRM record?

After the call ends, Retell runs post-call analysis on the transcript (the product calls it Post Call Extraction). The results then reach the CRM through one of three paths, depending on what your CRM supports and who should own the mapping logic.

What gets produced. Every call gets call_summary, user_sentiment, call_successful and in_voicemail. You add custom fields for your own outcomes, each typed as boolean, text, number or selector: qualified, budget_range, callback_requested. The call record also carries the full transcript and a recording URL. See post-call analysis for how fields are defined.

Path 1: the HubSpot Marketplace app. When the call completes, the app writes the summary and analysis to the contact's activity timeline, puts the recording and transcript in the call log, and shows the log on the associated company's timeline. The paused workflow then resumes and can branch on outputs like Call Success, User Sentiment or Call Outcome: a follow-up email on success, a retry or an SMS on no answer.

Path 2: native CRM integration. Retell's integrations with HubSpot, Salesforce, Microsoft Dynamics 365, GoHighLevel and Zoho CRM map post-call analysis fields onto contact fields and push them to the CRM record. Each mapping has an update mode: Overwrite for status fields, Fill only if empty for stable facts like email, or Accumulate & summarize to merge notes across calls. Turn on Log activities automatically and each call is also logged on the contact, as a Call engagement in HubSpot or a Task in Salesforce, for example. Post-call functions add targeted writes on top, such as a HubSpot Create Task that runs only when a followup_needed field is true.

One catch with Path 2: it writes only to contacts imported from the active CRM connection. A number that doesn't match a synced contact produces no activity record, and Retell updates existing CRM records rather than creating new ones unless you turn on Create new contacts in CRM.

Path 3: a webhook into your CRM. Retell posts a call_analyzed event to your endpoint with the full call object: transcript, recording URL, analysis results and the metadata you sent at trigger time. Your service reads the record ID from metadata and writes to the CRM's API. Verify the x-retell-signature header, and return a 2xx within 10 seconds, because Retell retries up to 3 times otherwise. Deduplicate on call_id so a retry never writes the same call twice. Listen for call_analyzed, not call_ended: the call_ended payload is sent before analysis runs, so it carries no analysis results.

What does the full trigger-to-writeback mapping look like?

The table maps common HubSpot triggers to what the agent does and what lands back on the record. The webhook path follows the same three columns.

Custom analysis fields are not filled for calls that never connected, so build the no-answer branch on the built-in fields and the call outcome, not on your custom ones.

What should you check before going live?

• Every enrolled contact has a valid E.164 phone number, and the workflow filters out the rest.
• The CRM credentials have write access to every object you write back to. In HubSpot, a missing scope doesn't flag the connection; the affected write just stops working.
• Each custom analysis field has a specific description for the LLM to extract against, and a matching CRM property exists.
• Post-call writes are gated, so a call that never connected writes nothing misleading.
• One system owns the timeline entry. The Marketplace app and the native integration are independent and can run together, so decide which one logs the call.
• Do-not-call is enforced where you expect it. Retell's do_not_call contact field doesn't block calls by itself; pass honor_internal_dnc: true on API calls to have Retell reject them, and keep your CRM's own suppression rules in the trigger.
• You test against a sandbox record. Testing a create or update tool writes a real record.

Where to start

If HubSpot is your system of record, the Retell HubSpot integration covers both halves of this loop: the native connection that gives the agent context and writes results back, and the Marketplace app that lets a HubSpot workflow place the call. For the click-by-click setup, including the private app scopes, follow the HubSpot setup guide. Running Salesforce, Dynamics 365, Zoho or something else? Start from the integrations directory, and use the webhook path for any CRM that isn't listed.

Related reading: The outbound phone number checklist, scoping a first partner deal, and more guides in the Retell Learn hub.