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

# Using Integrations In DialNexa Workflows

> Run DialNexa integration actions from workflow Application nodes with mapped variables, success paths, failure paths, and lead history.

DialNexa workflows use integrations through Application nodes. Wati templates use **Native** mode, while connected providers such as Resend use **Cloud** mode. Both paths can map lead data, post-call fields, call attributes, and static configuration into required fields.

<Warning>
  Cloud actions need explicit success and failure outputs. Native Wati uses one continuation output and continues even when Wati rejects a message, so confirm the Wati connection first and check delivery in Wati.
</Warning>

## Before You Begin

Connect and validate the provider, prepare test lead values, and map every required field before activation. For Cloud actions, wire explicit success and failure outputs. For native Wati, connect the single continuation output.

## DialNexa Workflow Integration Fields

These are the stored configuration keys behind an Application node - you never type them by hand. Picking the integration, action, and template in the node's dropdowns fills them in.

| Field | Purpose |
| - | - |
| `application_adapter_mode` | `native` for Wati template messages or `cloud` for connected hosted integration actions. |
| `provider_key` | Which integration provider to use, such as Wati or Resend. |
| `adapter_key` | How the provider is connected - the connection variant selected when the integration was set up. |
| `action_key` | Which operation to run, such as send WhatsApp template or send email. |
| `function_key` | The catalog function that implements the action, for catalog-based integrations (for example, Wati's send-message function). |
| `action_config` | Message body, template name, parameters, email fields, or other action inputs. |
| `outputs.success` | Next node after a successful Cloud provider result. |
| `outputs.failure` | Next node after a Cloud provider error or missing requirement. |

## Data Mapping Sources

<CardGroup cols={2}>
  <Card title="Lead variables" icon="braces" href="/docs/workflows/lead-variables-and-call-attributes">
    Values uploaded with the lead, such as name, phone number, email, city, or appointment date.
  </Card>

  <Card title="Call attributes" icon="database" href="/docs/monitoring/post-call-analysis-results">
    Runtime call values and post-call analysis values, such as interested, reason, preferred time, or support issue.
  </Card>

  <Card title="Static config" icon="settings" href="/docs/workflows/application-nodes">
    Fixed template name, broadcast name, subject, or text body.
  </Card>
</CardGroup>

Cloud integration nodes save only the action's status and message ID as lead variables, not the provider's response data. When a later node needs values returned by an external system, use a [Custom Function node](/docs/workflows/custom-function-nodes), which can save response values as lead variables.

## Wati And Resend Workflow Examples

| Workflow moment | Integration action | Required mapping |
| - | - | - |
| Lead booked an appointment | Native Wati template or Cloud Resend email. | Recipient phone or email, appointment date, time, location, agent name. |
| Call outcome is interested | Wati follow-up template. | Lead phone, template name, lead name, offer or next step. |
| Call outcome needs manual review | Resend email. | Ops recipient, call summary, call link or lead id, reason. |
| Payment reminder failed by WhatsApp | Resend fallback email. | Recipient email, amount, due date, support contact. |

## Build A Reliable Application Node

<Steps>
  <Step title="Validate provider connection">
    Do this before adding the node to an active workflow.
  </Step>

  <Step title="Choose the adapter mode">
    Select **Native** for **WhatsApp (Wati)** templates. Select **Cloud** for connected integrations and their workflow-safe functions. Wati is intentionally absent from the Cloud picker.
  </Step>

  <Step title="Sync and select Wati templates">
    For Wati, sync approved templates from the Integrations page first, then use the searchable template picker in the Application node.
  </Step>

  <Step title="Map every required field">
    Use lead variables, post-call analysis fields, call attributes, or static values. Empty fields should be intentional, not surprising.
  </Step>

  <Step title="Connect the available outputs">
    Name Cloud success and failure paths clearly. Native Wati has one continuation output.
  </Step>

  <Step title="Test one lead">
    Open the lead's history. For Cloud actions, it shows the provider, action, success or failure status, and an error summary on failure. For native Wati, check the message in Wati.
  </Step>

  <Step title="Scale only after the test is clean">
    One successful test should show the expected result in the provider account and the expected downstream branch.
  </Step>
</Steps>

Composio-backed cloud executions are billed in batches of `100` at approximately `INR 1.79` per batch. Billing does not block workflow execution, so review lead history and wallet transactions together.

## Workflow Integration Mistakes

<AccordionGroup>
  <Accordion title="No failure branch">
    Cloud provider actions can fail because of credentials, rate limits, template rules, missing fields, or invalid recipient data. Always route the Cloud failure output. Native Wati uses one continuation path and does not record send failures in lead history, so confirm the Wati connection and check delivery in Wati.
  </Accordion>

  <Accordion title="Static test data left in production">
    Replace hard-coded email addresses, phone numbers, and template parameters before launch.
  </Accordion>

  <Accordion title="Using call text instead of extracted fields">
    If a workflow needs a stable value, extract it into a post-call field first and map that field.
  </Accordion>

  <Accordion title="Action placed before data exists">
    A workflow node can only map fields that are already available at that point in the workflow.
  </Accordion>
</AccordionGroup>

## Verify The Workflow Integration

Run one successful action and one controlled failure. For Cloud actions, confirm the lead follows the expected success or failure output. For native Wati, confirm the message in Wati and verify the single continuation path. Lead history shows that the node ran and which template it used, not whether Wati accepted the message.

## Related Reading

<CardGroup cols={2}>
  <Card title="Application Nodes" icon="plug" href="/docs/workflows/application-nodes">
    Configure the workflow node.
  </Card>

  <Card title="Lead Variables" icon="braces" href="/docs/workflows/lead-variables-and-call-attributes">
    Map data into actions.
  </Card>

  <Card title="WhatsApp With Wati" icon="message-circle" href="/docs/dashboard-integrations/whatsapp-with-wati">
    Send WhatsApp messages.
  </Card>

  <Card title="Email With Resend" icon="mail" href="/docs/dashboard-integrations/email-with-resend">
    Send email messages.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.