How to Send Email from Zoho CRM with Volanea

If you need to send email from Zoho CRM without giving up control of deliverability, templates, or application-level email events, a workflow-triggered Volanea API call is a practical route. Zoho CRM can detect a record event, run server-side Deluge code, retrieve the relevant CRM data, and submit a transactional message to Volanea over HTTPS.

This is not a marketplace installation. Volanea does not provide a native Zoho CRM extension or a Zoho Marketplace plugin, so there is no “connect account” button inside Zoho CRM. The integration is an automation you own: Zoho CRM decides when an email should be sent, and Volanea handles the email send.

The approach in this guide uses a Zoho CRM workflow rule plus a custom function. That route is preferable to putting a Volanea API request in browser code or relying on a generic email alert when you need an API-based sending workflow. It also gives you a place to validate recipient data, prevent accidental repeat sends, and log the Volanea response back to the CRM record.

What this Zoho CRM and Volanea integration does

At a high level, the integration has four parts:

1. A Zoho CRM workflow rule watches a module and record event.
2. An instant action runs a Zoho CRM custom function when its criteria are met.
3. The Deluge function reads the record, builds the Volanea email request, and calls the Volanea REST API using invokeurl.
4. The function writes a send marker and, optionally, a provider message ID or error message back to the CRM record.

For a concrete example, this guide uses the standard Deals module. The event is a deal whose Stage changes to Closed Won. The function looks up the related contact, checks that the contact has an email address, and sends a welcome or next-steps email.

That event is deliberately specific. “Send an email every time a Deal is edited” is almost never a good automation rule: routine edits to owner, amount, close date, or notes can produce messages the contact did not expect. A stage transition, a form-created lead, or a record meeting a carefully defined workflow criterion is generally safer.

Why use a custom function rather than an email alert?

Zoho CRM email alerts are useful for simple CRM notifications, but a custom function is the better integration point when Volanea is your sending infrastructure. It lets you:

• Use an authenticated API request instead of exposing credentials in a URL or client-side integration.
• Construct HTML and plain-text content from CRM fields.
• Apply your own logic for missing email addresses, consent status, record ownership, and template selection.
• Store a durable “already sent” marker to make the workflow idempotent.
• Capture the HTTP response for support and troubleshooting.
• Keep sender identity and delivery infrastructure consistent with other product or transactional messages.

Before implementing the function, make sure your sending domain has been configured in Volanea and that you understand the request fields in the email API reference and setup guides. The CRM automation can decide who should receive a message; it cannot compensate for an unverified sender domain or an invalid recipient address.

The Zoho CRM trigger: a Deal stage change

In Zoho CRM, workflow rules are the automation mechanism that evaluates record events and conditions. Create a workflow rule for the Deals module with a record action based on edit, then narrow it to the Stage field being updated to Closed Won. Attach a custom function as an instant action.

The important point is that a workflow rule may be re-evaluated more than once during a record’s life. Do not assume “the workflow says Closed Won” automatically means “this message has never been sent.” Your function should make that decision explicitly.

Recommended fields to add to Deals

Create a small set of custom fields in the Deals module before wiring up the workflow. Exact field labels are your choice, but their purposes should be clear:

Use a checkbox for the send guard and date-time/text fields for the remaining values. Do not set the checkbox until the API call has returned a successful response. If it is set before the request completes, a temporary network failure can leave the deal marked as sent even though no message was accepted.

Workflow criteria to use

A conservative rule looks like this in business terms:

• Module: Deals
• Trigger: a record is edited
• Field change of interest: Stage
• Condition: Stage equals Closed Won
• Additional condition: Volanea Welcome Sent is false
• Action: instant action that invokes the custom function

The exact workflow-rule editor presentation can differ by Zoho CRM edition and UI changes, but the configuration principle remains the same: pass the Deal record ID into the custom function, and use record data—not a subject-line guess or front-end state—to decide whether to send.

If your actual use case is a new lead, substitute the Leads module and a “record is created” workflow event. If it is a customer onboarding message after an approved form submission, trigger the workflow only after the record has the fields that prove the form was completed. The recipient, consent state, and template inputs must all exist before the function calls Volanea.

What Zoho CRM actually passes to the function

A Zoho CRM workflow custom function does not receive an automatically generated, universal webhook JSON document. You define function arguments and map fields into those arguments when you add the custom function to the workflow.

For this integration, define one argument named dealId and map it to the Deal record ID. The effective input shape is therefore a single value:

dealId = "5725767000001234567"

That ID is not an email payload. It is a stable pointer to the CRM record. The function uses Zoho CRM’s server-side APIs to read the current Deal and its related Contact, then creates the JSON Volanea needs. This is safer than trying to put a secret-bearing HTTP request directly in a native webhook URL.

A typical CRM record relationship has this shape after it is fetched:

{
  "Deal_Name": "Annual plan — Northwind",
  "Stage": "Closed Won",
  "Amount": 12000,
  "Contact_Name": {
    "name": "Avery Morgan",
    "id": "5725767000000987654"
  },
  "Volanea_Welcome_Sent": false
}

The Contact_Name lookup contains a contact ID and display value, not necessarily every contact field you need. That is why the function fetches the contact record separately. From that record, it can retrieve fields such as Email and First_Name.

This distinction matters in production. A workflow can have valid Deal data but still lack a related contact, an email address, or consent to receive the class of email you intend to send. Treat each condition as a decision point, not as something Zoho CRM has already guaranteed.

Securely store the Volanea API key

The Volanea API key belongs only in a server-side secret store available to the Zoho CRM function. Never put it in a CRM portal page, a Zoho form’s client-side script, a browser extension, a public webhook URL, an email template, or a JavaScript bundle.

A recipient can inspect browser requests. A user with access to an embedded page can inspect client-side configuration. A key in either place can be copied and used to send mail as your authenticated domain.

Use a Zoho CRM organization variable or secured connection

For a Deluge function, store the key in a protected Zoho CRM administrative configuration location, such as an organization variable intended for server-side functions, or use a secured connection where your Zoho CRM configuration supports secret/header-based authentication. Give the configuration a descriptive internal name such as volanea.api_key.

The function should retrieve that value at runtime. Restrict who can view or change the organization-level setting, and do not log the value. The code below uses an organization variable to make the key lookup explicit:

volaneaApiKey = zoho.crm.getOrgVariable("volanea.api_key");

Use the precise variable mechanism available in your Zoho CRM account and test it with a non-production key first. If your organization uses a connection for secrets, keep the credential in that connection and have the function invoke the request through it rather than concatenating a key into source code.

Rotate credentials like infrastructure credentials

A CRM workflow is production infrastructure once it can send customer email. Document the key owner, creation date, and rotation process. When rotating a Volanea key, update the secure Zoho setting, test a controlled record, and revoke the old key only after the new configuration succeeds.

Avoid copying an API key into a Deluge code comment while debugging. Also avoid logging request headers, complete request maps, or raw exceptions if they can include authorization data. Log only the HTTP status, non-sensitive response data, record ID, and an internal correlation value.

Build the Volanea request in Deluge

The following example is a full pattern for the Closed Won Deal workflow. It retrieves the Deal, checks the send marker, resolves the related Contact, validates the contact’s email, creates a JSON payload, and posts it to Volanea.

The Volanea request body used here has a sender, a recipient list, a subject, an HTML body, and a text body. Keep the field mapping close to the code so future CRM field changes do not silently change what customers receive.

// Workflow custom-function argument: dealId
// Map dealId to the Deals record ID in the workflow action.

deal = zoho.crm.getRecordById("Deals", dealId);

if(deal == null || deal.isEmpty())
{
    info "Volanea send skipped: Deal not found: " + dealId;
    return;
}

// Idempotency guard: do not send again after a successful prior send.
if(deal.get("Volanea_Welcome_Sent") == true)
{
    info "Volanea send skipped: already sent for Deal " + dealId;
    return;
}

contactLookup = deal.get("Contact_Name");
if(contactLookup == null || contactLookup.get("id") == null)
{
    updateData = Map();
    updateData.put("Volanea_Send_Error", "No related contact on this Deal");
    zoho.crm.updateRecord("Deals", dealId, updateData);
    return;
}

contactId = contactLookup.get("id");
contact = zoho.crm.getRecordById("Contacts", contactId);
recipientEmail = ifnull(contact.get("Email"), "").trim();
firstName = ifnull(contact.get("First_Name"), "there");
dealName = ifnull(deal.get("Deal_Name"), "your new plan");

if(recipientEmail == "")
{
    updateData = Map();
    updateData.put("Volanea_Send_Error", "Related contact has no email address");
    zoho.crm.updateRecord("Deals", dealId, updateData);
    return;
}

// Read this from a server-side organization variable or secret-backed connection.
volaneaApiKey = zoho.crm.getOrgVariable("volanea.api_key");
if(volaneaApiKey == null || volaneaApiKey == "")
{
    info "Volanea send skipped: API key configuration is missing";
    return;
}

// This is the exact JSON shape submitted to Volanea.
toRecipient = Map();
toRecipient.put("email", recipientEmail);
toList = List();
toList.add(toRecipient);

fromSender = Map();
fromSender.put("email", "hello@your-verified-domain.example");
fromSender.put("name", "Your Company");

htmlContent = "<p>Hi " + firstName + ",</p>" +
              "<p>Thanks for choosing us for <strong>" + dealName +
              "</strong>. Your next steps are ready.</p>";
textContent = "Hi " + firstName + ",\n\n" +
              "Thanks for choosing us for " + dealName +
              ". Your next steps are ready.";

emailPayload = Map();
emailPayload.put("from", fromSender);
emailPayload.put("to", toList);
emailPayload.put("subject", "Welcome — here are your next steps");
emailPayload.put("html", htmlContent);
emailPayload.put("text", textContent);

headers = Map();
headers.put("Authorization", "Bearer " + volaneaApiKey);
headers.put("Content-Type", "application/json");
headers.put("Accept", "application/json");

response = invokeurl
[
    url :"https://api.volanea.com/v1/emails/send"
    type :POST
    parameters:emailPayload.toString()
    headers:headers
];

// On a successful API response, store a durable send marker.
// Adapt the response key below if your Volanea API response uses a different ID field.
updateData = Map();
updateData.put("Volanea_Welcome_Sent", true);
updateData.put("Volanea_Welcome_Sent_At", zoho.currenttime);
updateData.put("Volanea_Send_Error", "");
if(response != null && response.get("id") != null)
{
    updateData.put("Volanea_Message_ID", response.get("id"));
}
zoho.crm.updateRecord("Deals", dealId, updateData);

Field mapping, line by line

The important mapping in the example is not hidden behind a generic connector:

Do not use a CRM field as from.email unless you tightly validate it against domains you control. Letting arbitrary users or records select the From domain can cause authentication failures, confusion, or spoofing-like behavior. A verified, intentional sender address is the default for transactional messages.

Also consider adding a business reference in a metadata or tag field if supported by your Volanea account and API version. A Deal ID makes later investigation much easier. Do not place sensitive CRM data, such as full contact notes or payment details, in a subject line, tag, or event field that may be broadly visible to operational users.

Test the workflow before enabling it for every deal

Use a test sender domain, a test contact, and a disposable inbox before enabling the workflow for your sales pipeline. CRM automations are easy to trigger at scale; a condition error can send messages to many records quickly.

A useful test sequence is:

1. Create a test Contact with an inbox you control and a valid email address.
2. Create a test Deal associated with that Contact while the Deal is in a non-winning stage.
3. Change Stage to Closed Won once.
4. Confirm that the workflow history shows the function execution.
5. Confirm the Deal gets the sent timestamp and Volanea message ID after the API accepts the message.
6. Inspect the received email: sender, recipient, subject, personalization, plain-text fallback, links, and authentication results.
7. Edit an unrelated Deal field and confirm no second email is sent.

Test negative cases as well. Remove the contact email address, remove the contact lookup, and temporarily use an invalid sender or key in a non-production environment. Each case should either stop safely or create a clear error record; none should mark the Deal as successfully sent.

Validate recipient data before you send

A non-empty CRM Email field is not necessarily a deliverable mailbox. It may contain a typo, a role address, an old address, or a value copied from a form without validation. For high-value workflows, validate the address before the deal reaches the trigger or route uncertain addresses to a review queue. Volanea’s free email address verification tool can help assess an address before it becomes a recipient in an automated workflow.

Validation is not a replacement for consent and preference handling. A Deal reaching Closed Won may justify a service-related onboarding message, but it does not automatically establish permission for recurring promotional mail. Keep marketing enrollment, unsubscribe status, and lifecycle consent as explicit CRM fields and make the workflow respect them.

When this breaks: diagnose the Zoho-to-Volanea hop

The failure boundary is clear: Zoho CRM runs the function, and the function makes an HTTPS request to Volanea. Problems on either side can result in no send, an uncertain send, or—most dangerously—a duplicate send.

Retries can create duplicate email

Automation systems may retry an execution after a timeout or transient delivery failure. A timeout does not prove that Volanea rejected the request; Volanea may have accepted the message while Zoho CRM did not receive the response in time. If the same workflow execution is retried without a durable guard, the recipient can receive two emails.

The Volanea_Welcome_Sent field protects against ordinary later edits, but it cannot solve the narrow uncertainty window between Volanea accepting the request and Zoho CRM updating that checkbox. For higher-stakes messages, use an idempotency strategy supported by your sending API, or generate and persist a unique send key before the request. A useful key can be based on the Deal ID plus message purpose, such as deal-5725767000001234567-welcome-v1.

If your Volanea API supports an idempotency header or message identifier, send that stable value on every retry of the same business event. Do not generate a fresh random value for each retry; doing so defeats deduplication. If API-level idempotency is unavailable, a small middleware service with a durable database can claim the send key before calling Volanea.

Webhook or function timeouts

A native Zoho CRM webhook and a Deluge invokeurl call are synchronous HTTP steps with platform limits. A slow endpoint, DNS problem, TLS problem, or service interruption can cause the function to time out. Keep the send path short: do not fetch unrelated records, call multiple external systems serially, or render large documents inside the same transaction.

Treat a timeout as an unknown outcome, not as a guaranteed failure. Check Volanea activity or message records using the stored correlation data before manually rerunning a Deal. If the message exists, set the CRM marker rather than sending again. If it does not, retry under a controlled process.

For workflows where a CRM user must not wait on an external API, use a queue or middleware service. Zoho CRM can initiate the job, the middleware can return quickly after accepting it, and a worker can handle retries, idempotency, and observability independently.

Missing fields and edition-specific automation limits

Zoho CRM automation capabilities, limits, and available actions can vary by edition, permissions, enabled features, and administrative settings. A field that exists in a sandbox may not exist in production; a custom function may lack permission to read Contacts; or a workflow may not be available in the edition used by a particular CRM organization.

Build defensive checks for every required value: the Deal, the related Contact, the Contact email, the API secret, and the verified From address. In addition, confirm that the workflow user and function context can access the module and fields involved. A missing lookup or inaccessible field should write an internal error and stop, not create a malformed request with an empty recipient.

Bad request and authorization responses

An HTTP 401 or 403 generally points to a missing, expired, revoked, or incorrectly formatted Volanea API credential. A 400-class validation response generally points to the request shape, a bad sender, an invalid recipient, or content that violates a required field constraint. A 500-class response or network error is a candidate for a controlled retry.

Do not blindly mark every invokeurl response as success. In production, expand the example’s response handling to inspect status and error fields documented by Volanea, then update Volanea Send Error with a concise non-secret message. Preserve the full technical detail in a restricted log system if your operational process requires it.

Native webhooks, Zapier, Make, and middleware alternatives

Zoho CRM also supports webhooks as workflow actions, but a native webhook is best when the receiving endpoint is designed for the request Zoho emits. A direct Volanea email request needs an authorization header, a correctly structured JSON body, and often data from related records. That makes a custom function the more flexible direct route.

A no-code intermediary can be appropriate when you cannot use custom functions in your Zoho CRM setup or when the business wants to maintain the mapping without Deluge. In that architecture, Zoho CRM sends a webhook to Zapier or Make, and the intermediary calls Volanea. Keep the Volanea API key in the intermediary’s protected connection or secret store—not as a visible Zoho webhook parameter.

Middleware is the strongest option when delivery volume, compliance, or operational complexity grows. A small service can receive a minimal event containing a CRM record ID, retrieve or accept only approved fields, enforce consent rules, create a stable idempotency key, call Volanea, and write status back to Zoho CRM. It is more work than a custom function, but it centralizes audit logs, retry policy, and email policy across systems.

Choose based on the consequence of an error:

• Custom function: strong fit for a straightforward, low-to-moderate-volume transactional workflow owned by CRM administrators and developers.
• Zapier or Make: useful for quick orchestration where no-code maintenance matters and the intermediary can safely retain the secret.
• Middleware: best for high volume, strict duplicate prevention, extensive observability, complex templates, or multiple source systems.

Design the email as a transactional event, not a CRM blast

A Closed Won message should answer the recipient’s immediate question: what happens next? It should not read like a generic bulk campaign unless the recipient explicitly opted into marketing content.

Keep the message focused on the record event that caused it. For example, a new-customer email can state that the purchase or agreement is confirmed, identify the next onboarding action, provide a support route, and include one clear destination. It should not expose internal deal fields, sales notes, pricing negotiations, or account-owner details unless those are intentionally customer-facing.

Maintain both HTML and plain-text bodies. The HTML version can add structure and branded links; the plain-text version improves accessibility and provides a reasonable fallback in clients that do not render HTML as expected. Test both versions with real CRM field values, including long names, punctuation, international characters, and missing optional values.

Use an intentional template versioning practice. If an onboarding email changes materially, record which version was sent in Zoho CRM or in your application’s metadata. That gives customer success teams context when a recipient replies about instructions they received weeks earlier.

Operational checklist for a durable integration

Before turning the workflow on, review this checklist with the CRM administrator and the person responsible for email infrastructure:

• The Volanea sending domain and From address are verified.
• The workflow has one explicit business trigger, such as a Deal stage transition to Closed Won.
• The custom function receives a record ID and fetches current data server-side.
• The function checks for a related Contact and a non-empty email address.
• The Volanea API key is stored in a server-side Zoho secret/configuration location.
• The key is not hard-coded in Deluge, exposed in a URL, or stored in browser-visible configuration.
• A CRM send marker prevents normal repeat edits from resending the same message.
• Timeout and retry behavior has an idempotency plan.
• The function writes a useful success reference and concise failure detail back to the record.
• Test records have verified the happy path, missing-data path, unauthorized-key path, and repeat-edit path.
• Consent, subscription status, and suppression requirements are evaluated before non-transactional mail is sent.

Review workflow history and email outcomes after launch. The first week usually surfaces real-world data issues: contacts missing email addresses, Deals without a linked Contact, unexpected workflow re-entry, and names that need safer fallback handling. Fix the workflow and data model rather than asking users to work around recurring errors manually.

Conclusion

To send email from Zoho CRM with Volanea, use Zoho CRM’s workflow automation to detect a meaningful record event and a server-side custom function to make the authenticated API call. For a Deal that reaches Closed Won, the function can resolve the linked Contact, map CRM data into a transactional email payload, and record the result on the Deal.

The essential safeguards are just as important as the request itself: keep the API key out of client-visible configuration, validate CRM data before sending, use a sent marker, and plan for retry ambiguity. Once those controls are in place, the integration is a maintainable bridge between your CRM lifecycle events and your email infrastructure.

FAQ

Can I install Volanea from the Zoho CRM Marketplace?

No. Volanea does not provide a native Zoho CRM Marketplace app for this workflow. Use a Zoho CRM workflow rule with a custom Deluge function, or route the event through Zapier, Make, or your own middleware.

What Zoho CRM event should trigger the email?

Use a workflow rule tied to a meaningful record event, such as a Deal’s Stage changing to Closed Won, a Lead record being created, or a record satisfying an approved onboarding condition. Avoid broad “any edit” triggers without a send guard.

Where should I store the Volanea API key in Zoho CRM?

Store it in a server-side organization-level secret/configuration mechanism or a secured connection available to the custom function. Never place it in a browser script, public webhook URL, email template, or hard-coded source code.

How do I stop duplicate emails after a workflow retry?

Store a sent marker on the CRM record after success and use a stable idempotency key for the business event when your sending API supports it. Treat timeouts as unknown outcomes and check the provider record before manually retrying.

Can I send marketing campaigns from this workflow?

Technically, a workflow can initiate an API request, but a stage change alone does not establish marketing consent. Separate transactional messages from promotional campaigns, check subscription and suppression fields, and use an appropriate consent-aware campaign process for marketing mail.