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

# Workflow Lead Variables And Call Attributes In DialNexa

> Understand DialNexa workflow lead variables, call attributes, uploaded values, variable keys, application templates, and condition routing.

Workflow lead variables and call attributes carry data through a DialNexa workflow. Lead variables usually come from uploaded or created lead data. Call attributes come from call results, metadata, or extracted fields. Together they power conditions, templates, and debugging.

<Tip>
  Variables are the workflow memory. If memory is empty, conditions and templates will improvise badly.
</Tip>

## Lead Data Types

Use the right data source for the right job.

| Data              | Source                                            | Used by                             |
| ----------------- | ------------------------------------------------- | ----------------------------------- |
| Phone number      | Lead creation or CSV upload.                      | Voice Call nodes.                   |
| Dynamic variables | Uploaded lead columns or API-created lead values. | Prompts, templates, and conditions. |
| Call attributes   | Call result data and post-call analysis.          | Condition nodes and reporting.      |
| Notes             | Lead context where available.                     | Review and operations.              |
| Current node id   | Execution state.                                  | Lead history and debugging.         |

## Where Variables Appear

Workflow variables show up across builder and execution.

<CardGroup cols={2}>
  <Card title="Condition nodes" icon="git-branch" href="/workflows/condition-nodes">
    Branch on variables or call attributes.
  </Card>

  <Card title="Application nodes" icon="plug" href="/workflows/application-nodes">
    Insert values into Wati templates or email fields.
  </Card>

  <Card title="Lead history" icon="route" href="/workflows/lead-history-and-debugging">
    Show which data was available when the lead moved.
  </Card>

  <Card title="Call logs" icon="activity" href="/monitoring/call-detail-page">
    Call attributes can be traced back to exact call records.
  </Card>
</CardGroup>

## Variable Hygiene Questions

<AccordionGroup>
  <Accordion title="Are variable names stable?">
    Changing a column name can break templates and conditions.
  </Accordion>

  <Accordion title="Are values present for every lead?">
    Use defaults or validation before activation.
  </Accordion>

  <Accordion title="Are call attributes created before they are used?">
    A condition cannot branch on an outcome that has not happened yet.
  </Accordion>

  <Accordion title="Are sensitive values necessary?">
    Avoid carrying sensitive data through workflow variables unless required.
  </Accordion>
</AccordionGroup>

## Workflow Variables And Activation

Workflow activation now checks whether lead variables used in conditions or application node templates have matching workflow-level fallback values. A lead variable is any simple `{{variable_name}}` placeholder that is not a runtime call attribute.

| Variable source                                                                         | Activation behavior                                                              |
| --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| Condition node field such as `dynamic_variables.plan_name`                              | Requires a matching Workflow Variable before activation.                         |
| Application node template or action field containing `{{plan_name}}`                    | Requires a matching Workflow Variable before activation.                         |
| Runtime call attributes such as `{{call_id}}`, `{{call_status}}`, or `{{call_summary}}` | Does not require a workflow fallback because DialNexa injects it at runtime.     |
| Existing leads missing a referenced variable                                            | Activation can warn that those leads will use the workflow-level fallback value. |

Add workflow fallback values before activation when a variable may be missing from uploaded lead data. This prevents application templates and conditions from receiving empty placeholders.

### Runtime Call Attributes

The activation check treats these as runtime attributes rather than lead CSV columns: `lead_phone`, `customer_phone`, `recipient_phone_number`, `workflow_lead_id`, `call_log_id`, `call_id`, `call_status`, `call_duration`, `call_duration_seconds`, `call_sentiment`, `call_summary`, `pca_summary`, and `pca_intent`.

## Related Reading

<CardGroup cols={2}>
  <Card title="Condition Nodes" icon="git-branch" href="/workflows/condition-nodes">
    Route with data.
  </Card>

  <Card title="Application Nodes" icon="plug" href="/workflows/application-nodes">
    Use data in actions.
  </Card>

  <Card title="Call Data Model" icon="database" href="/data/call-data-model">
    Understand call fields.
  </Card>
</CardGroup>