A connection failure occurs when Cleo Integration Cloud (CIC) cannot establish or maintain a connection to an external system, endpoint, or trading partner during processing. When this happens, messages or jobs fail or remain unprocessed.
Guided Resolution for Connection Failures provides a guided way to understand and respond to these failures. When a connection failure is detected, Guided Resolution analyzes available error information and presents an explanation of the issue along with recommended next steps. Connection failures occur due to issues such as invalid credentials, endpoint configuration problems, certificate issues, or unavailability of the external system. Guided Resolution is part of CIC’s Intelligent Exception Management capability.
How Guided Resolution works for connection failures
When a connection failure occurs, Guided Resolution presents its analysis across two tabs on the issue:
- Issue tab: an AI-generated summary explaining why the connection failed, key fields specific to the failure type (for example, endpoint name, protocol, or direction) with tooltips, and counters showing how many jobs, messages, and payloads are affected.
- Resolution & Recovery tab: a Root Cause explanation referencing the specific endpoint or error involved, followed by one or more Recommended Fix Options and, at the bottom, payload/message recovery actions. Select “Go to resolution…” from the Issue tab to jump here.
All AI-generated content carries the disclaimer: “This content is AI-generated and may contain inaccuracies.”
Connection failures are categorized into seven types, each with its own typical causes and resolution path: Protocol, Authentication, Connection, File System, Routing, Packaging, and Connector. Guided Resolution identifies the type automatically and tailors the summary, key fields, and recommended actions to it. See Connection failure types below for details on each.
Connection failure types
| Failure Type | Description | Notification Routing |
|---|---|---|
| Protocol | A failure during a transfer or message exchange over a communication-protocol endpoint (AS2, SFTP, HTTP) — the connection or send operation doesn't complete: it times out, is refused, returns an error response, drops mid-stream, or the expected acknowledgement never arrives. Distinct from Connection errors: the connection is made, but the exchange itself fails to complete. | Server owner is typically the partner — Notify Partner appears when the platform identifies the far end as partner-owned. |
| Authentication | Credentials, keys, or certificates were rejected by the remote endpoint. | Notify Partner appears if the partner owns the server; otherwise View Endpoint Config is recommended first. |
| Connection | A network-level failure prevented a session from being established (timeout, refused connection, DNS failure). | Server ownership drives whether Notify Partner or Notify Internal Team is offered. |
| File System | A local or remote file system operation failed (permission denied, path not found, disk full). | Typically routed to Notify Internal Team, since file system issues are usually tenant-side. |
| Routing | CIC could not determine the correct data flow or destination for the message. | Usually routed to Notify Internal Team. |
| Packaging | The outbound or inbound file could not be packaged or unpackaged correctly (for example, an AS2 MDN mismatch or envelope error). | Server ownership determines Notify Partner vs. Notify Internal Team. |
| Connector | A third-party connector (API-based integration) returned an error or could not complete the requested operation. | Typically routed to Notify Internal Team unless the connector is partner-managed. |
Recommended actions
The fix options shown depend on the failure type and are generated dynamically. You could see any combination of the following:
- Retry: reprocesses the affected payloads or messages.
- Notify Partner: opens a read-only, pre-drafted email addressed to the trading partner. Shown only when the platform identifies the partner as owning the far-end server.
- Notify Internal Team: opens a read-only, pre-drafted email for your internal team with full technical detail.
- View Endpoint Config: opens the endpoint’s configuration screen.
- View Data Flow: opens the related data flow in Integrations > Data Flows.
- Copy Details: copies a structured diagnostic block to your clipboard for escalation.
Whether Notify Partner or Notify Internal Team appears is determined automatically from server ownership. You don’t need to work this out yourself. See the FAQ below.
Below the Recommended Fix Options, the Resolution & Recovery tab always shows a Recovery section with three actions for bulk-handling the files and messages affected by this issue. Unlike the fix options above, these three actions are always available regardless of which failure type or fix options Guided Resolution recommends.
Address the root cause first. Recovering payloads or messages before the underlying issue is fixed (for example, before credentials are corrected or the endpoint is back online) will typically just reproduce the same failure. Use the Root Cause explanation and fix options above to confirm the issue is resolved before recovering.
Recover Impacted Payloads: Select the affected payloads for bulk reprocessing. CIC automatically determines whether to reprocess the target payload or re-receive the source payload based on where in the pipeline the failure occurred. You don’t need to choose.
Recover Messages: Select the affected messages for bulk message-level reprocessing.
Download: Download the raw payload or message files for the affected issue.
Limitations
Guided Resolution does not automatically correct configuration issues or make changes on your behalf. Resolving a connection failure can require coordination with internal teams or external trading partners. Partner and internal notification drafts are copy-to-clipboard only. Guided Resolution does not send email on your behalf.
FAQ
Q: What does “retryable” mean?
A: It’s a flag Guided Resolution sets on a failure indicating whether reprocessing is likely to succeed without further changes. A failure can be retryable even if the underlying cause hasn’t been fixed yet. You should always read the Root Cause explanation first.
Q: What’s the difference between Recover Payloads and Recover Messages?
A: Recover Payloads reprocesses the underlying file(s) and automatically routes to source re-receive or target reprocess depending on where the failure occurred. Recover Messages reprocesses at the message level. If you're not sure, Recover Payloads is the more common starting point for connection failures.
Q: How does CIC decide whether to show Notify Partner?
A: Server ownership (partner vs. tenant) is determined automatically from the endpoint configuration. Notify Partner only appears when the far-end server is identified as partner-owned.
Q: What if the recommended fix doesn’t resolve the issue?
A: Use Copy Details to capture the diagnostic block and escalate to your integration team or Cleo Support.
Related articles
Comments
0 comments
Please sign in to leave a comment.