Skip to main content
When a call arrives, DialNexa knows the caller’s phone number. With a function call that queries your CRM or database, you can translate that phone number into a customer record — name, account tier, last interaction, open tickets — and make it available to the agent before the first substantive exchange. This pattern transforms a generic “How can I help you?” into a personalized “Hi Priya, welcome back. I see your last appointment was on March 10. How can I help you today?”

The pattern

  1. Call connects. DialNexa has {{caller_number}} (the caller’s phone number in E.164 format).
  2. A function call queries your CRM/database with {{caller_number}} as the lookup key.
  3. The CRM returns the customer record (or signals no record found).
  4. Variables populate from the response: {{customer_name}}, {{account_tier}}, {{last_service}}, etc.
  5. The agent’s greeting and subsequent turns use these variables.
The lookup should complete before the agent’s first substantive turn. Design your flow to handle both the case where a record is found and the case where it is not.

Implementation: single-prompt agents

In a single-prompt agent, caller lookup is implemented by defining a CRM lookup function in the agent’s Tools and instructing the agent to call it at the start of every conversation. Step 1: Define the lookup function In Settings > Tools, add a function:
{
  "name": "lookup_caller",
  "description": "Look up a customer record by phone number. Call this at the start of every conversation before responding to the caller.",
  "parameters": {
    "type": "object",
    "properties": {
      "phone_number": {
        "type": "string",
        "description": "The caller's phone number in E.164 format"
      }
    },
    "required": ["phone_number"]
  }
}
Step 2: Configure the function endpoint Set the endpoint URL for the lookup_caller function. Your endpoint receives:
{
  "function": "lookup_caller",
  "parameters": {
    "phone_number": "+919876543210"
  },
  "session_id": "sess_xxxxxxxx"
}
And returns:
{
  "found": true,
  "customer": {
    "name": "Priya Sharma",
    "account_id": "ACC-12345",
    "tier": "premium",
    "last_service_date": "2024-02-10",
    "last_service_type": "haircut",
    "open_complaints": 0
  }
}
Or, if no record exists:
{
  "found": false
}
Step 3: Update the system prompt Add explicit instructions to call the lookup function immediately:
At the start of every conversation, before responding to the caller, call the lookup_caller function with the caller's phone number ({{caller_number}}).

If the lookup returns found=true:
- Address the caller by name (customer.name)
- Personalize the greeting based on their history

If the lookup returns found=false:
- Greet them as a new caller
- Ask for their name early in the conversation
Instruct the LLM to call the function before its first verbal response. Without this instruction, the LLM may greet the caller first and then call the function, causing the personalization to appear mid-conversation rather than at the start.

Implementation: conversational flow agents

In a conversational flow agent, implement the lookup as a Function Node at the very start of the flow, before any greeting node.
1

Add a Function Node as the first node

Place a Function Node at the start of your flow, connected from the call start trigger. Do not put a greeting node before it.
2

Configure the function call

Set the function to lookup_caller (or your equivalent). Pass {{caller_number}} as the phone number parameter.
3

Map response fields to variables

In the Function Node’s response mapping, map each returned field to a variable:
Response fieldVariable
customer.name{{customer_name}}
customer.tier{{account_tier}}
customer.last_service_type{{last_service}}
found{{caller_found}}
4

Branch on lookup result

Connect two branches from the Function Node:
  • Caller found (condition: {{caller_found}} == true) → personalized greeting node
  • Caller not found / error → generic greeting node that asks for the caller’s name
5

Use variables in greeting nodes

In the personalized greeting node, reference the populated variables:“Hi {{customer_name}}, welcome back. Your last appointment was a {{last_service}}. How can I help you today?”

CRM query examples

REST API (typical CRM):
GET https://api.your-crm.com/customers?phone={phone_number}
Authorization: Bearer {crm_api_key}
Salesforce (via custom middleware):
SELECT Id, Name, Phone, Account.Type FROM Contact WHERE Phone = '{phone_number}' LIMIT 1
Airtable:
GET https://api.airtable.com/v0/{base_id}/{table}?filterByFormula=({Phone}="{phone_number}")
In all cases, your function handler is responsible for the API call, transformation, and returning the standardized response format. DialNexa calls your endpoint — it does not query your CRM directly.

Handling lookup failures

Your CRM lookup can fail in three ways:
  1. No record found: caller is new. Proceed without personalization or ask for their name.
  2. Function call timeout: your endpoint did not respond within the timeout window. Default to no personalization; log the error for investigation.
  3. Function call error: your endpoint returned an error status. Treat the same as timeout.
Always configure the fallback branch. If the Function Node errors with no fallback, the flow will stall. Add | default: guards on all variables that come from the lookup:
"Hi {{customer_name | default: \"there\"}}, how can I help you today?"

Privacy considerations

The caller’s phone number ({{caller_number}}) is available by default. If your data handling policy restricts phone number use for lookup purposes, do not implement this pattern without confirming compliance. The phone number passed to your function endpoint is subject to your privacy policy and any applicable regulations (GDPR, PDPA, DPDPA).