Retries and failures
Outbound behavior differs by integration — some retry automatically, most don't. Here's what actually happens today, integration by integration.
| Integration | Automatic retry? | Behavior |
|---|---|---|
| Zoho CRM (call log / note) | No | A failed push is logged in Activity; nothing re-attempts it automatically |
| Zoho CRM (RNR follow-up) | Yes, but it's a re-call, not a re-push | A weekly Sunday sweep re-dials leads matching a configured disposition — this retries the call, not a failed data push |
| Zoho Desk (ticket) | Partially | Ticket creation itself isn't retried, but follow-up actions (attachments, tagging, one-time status refresh) fail soft — a failure in any of them never undoes or fails the ticket that was already created |
| LeadSquared | No | Failures are logged in Activity; LeadSquared's own webhook delivery may retry on their side, but a failed outbound push from Sprio isn't automatically retried |
| No | A failed send (including the "200 with success:false" gateway quirk) is logged as a failure; no automatic resend | |
| Email (SMTP) | No (but deferred sends aren't "failures" until they actually fire) | A deferred (after_call) email is held and flushed once, at call end — if that single send fails, it isn't retried |
What this means in practice
Don't assume automatic recovery. If a push fails — a CRM is briefly down, a token expired, a field validation error — the general pattern across every integration is: log it, don't silently retry it. If you need guaranteed delivery for a specific integration, that's worth raising as a requirement rather than assuming it already happens.
Check Activity, not just the target system. A push can fail in a way that's invisible from the CRM/ticket system's own side (e.g. Sprio never sent the request at all because a run condition didn't match). The Integrations → Activity tab on each connection is the single place that distinguishes "correctly skipped" from "attempted and failed."
Two real error classes to expect:
- Schema mismatches — a mapped field that doesn't exist on the target
system's schema (e.g. Zoho's
MXUnknownAttributeExceptionfor a field that isn't on a particular tenant) rejects the whole push, not just that field. - Uniqueness conflicts — target-system constraints (e.g. LeadSquared's optional unique-Phone constraint) can reject a push for a legitimate repeat contact; see each integration's page for the specific workaround.