Sign in

Diagnose a non-functional channel connection

An Admin opens a connection showing a problem, reviews its recent error history, runs an on-demand test, and is guided to the specific fix for the error class rather than left to interpret a raw provider error.

When this happens: Admin opens a connection row from UC-15.1, or follows the deep link in an FR-10 UC-10.9 notification.

Step by step

  1. 1

    Open the *Sales — RO* WhatsApp connection, showing Error.

    EasyCRM shows the connection detail: header (state, last successful sync, consecutive failures), and the diagnosis panel with the last 20 entries of ChannelConnectionErrorLog, newest first.

  2. 2

    Reads the most recent entry: TokenExpired, provider message Error validating access token.

    EasyCRM shows the guided fix for TokenExpired: Re-authorize this connection with a button.

  3. 3

    Click Re-authorize this connection.

    Routes to the channel's reconnect flow with the existing connection identity.

  4. 4

    Completes re-authorization.

    Sets Active, clears the error fields, and shows Connection restored on returning to the detail screen.

Other paths

Test connection without a known error

On a connection that looks fine but a customer reported an issue, clicks Test Connection. Calls the provider with a lightweight, side-effect-free probe and shows Connection is working or a normalized error within 10 seconds; the attempt is appended to the timeline either way.

Rate-limited error — no action needed

If the latest error is RateLimited. The guided fix reads This provider is temporarily limiting requests. No action needed — the platform will retry automatically, with no action button.

If something goes wrong

Unrecognized provider error

If the provider returned an error the adapter could not normalize. The guided fix reads Contact support with this error code and timestamp, and the raw provider message is shown for reference.

Re-authorization fails

If the reconnect attempt itself fails (e.g. The Admin cancels, or the provider rejects the new credential). The connection stays in its prior state (or moves to RequiresReauth if the new attempt also fails credential validation), and the failure is appended to the error history.

Good to know

  • The guided fix is derived from the most recent normalized ErrorCode, not the raw provider message.
  • A successful Test Connection does not by itself clear Degraded/Error — only a real send/receive success or the next health-check cycle does.
  • Test Connection never sends a message to a real customer.