Skip to main content
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.
Variables are the workflow memory. If memory is empty, conditions and templates will improvise badly.

​
DialNexa Workflow Lead Variables And Call Attributes

Use the right data source for the right job.

​
Where Variables Appear

Workflow variables show up across builder and execution.

Condition nodes

Branch on variables or call attributes.

Application nodes

Insert values into Wati templates or email fields.

Lead history

Show which data was available when the lead moved.

Call logs

Call attributes can be traced back to exact call records.

​
Variable Hygiene Questions

Changing a column name can break templates and conditions.
Use defaults or validation before activation.
A condition cannot branch on an outcome that has not happened yet.
Avoid carrying sensitive data through workflow variables unless required.

​
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. 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.

Condition Nodes

Route with data.

Application Nodes

Use data in actions.

Call Data Model

Understand call fields.