When a record fails to sync, an error lands in your error queue. This guide shows how to work through it with the MCP, from "something failed" to "the record arrived", without guessing. You stay in control the whole way: the assistant suggests, you approve, and nothing changes until you confirm.

Ask in plain language. For example:

Each error in the queue records what failed, the connected system, the scope (such as product/updated), the direction, the external ID, the status, the number of attempts and a reference ID. The reference ID is the ID of the job that produced the error (the hook ID a resync returns), and it is the usual way in. A sync's tracking ID is a different ID and doesn't match an error.

Every error has a status:

The assistant filters by one thing at a time, such as a job ID, a connected system or a status. If you give it two, it will ask you to pick one.

Pick an error and ask the assistant to diagnose it. You can give it the error's own ID or the job ID. It reads the error, finds any error code in the message, and sorts it into one of these:

Older integrations sometimes report plain-English messages with no code. For those, the assistant uses its best judgement about what the message points to, such as a connection, a credential or a record that wasn't found, and it tells you when it is guessing.

The diagnosis also hands the assistant everything it needs to resync the record later, because the error already holds the connected system, the scope, the direction and the external ID.

An error message alone is rarely enough to choose a fix. Ask the assistant to find the help articles for the error. It searches the integration's Error Messages article for the exact text, which documents most failures with a code, a cause and a fix. For platform codes it points to the codes reference, and for external-system failures it points to that vendor's own documentation.

A good prompt is: "Read the help article for this error, then tell me what you think the fix is and why." If the assistant proposes a fix without a source, ask where it came from.

Twenty errors are usually three causes. Ask the assistant to plan a fix for a job ID, a connected system or a status. It groups the errors by root cause, so records that fail for the same reason are counted together, and orders the groups:

The plan itself changes nothing. For each group it lays out the same sequence: propose the fix, get your approval, apply it with a preview, retry the record that failed first, retry the other records in the group to prove the fix didn't break them, then re-check the queue.

Fix one cause at a time and verify it before moving to the next. If you apply two fixes before checking either, you can't tell which one worked.

What you change depends on the cause. Here are the usual ones:

Every change goes through the preview-and-confirm steps described in Safety, Permissions and Limits. Read the preview before you confirm.

Once the fix is in, resync the record that originally failed, and only that one. Ask the assistant to resync it. It shows a preview that names:

The preview also checks that the integration supports that data type and direction, and it stops if not. The assistant can take these values from the error itself, but check them before you confirm.

When that one record works, resync the rest of the group, up to 25 at a time.

A resync starts a background job. Starting it doesn't mean the record arrived, so the resync checks each record and reports whether it was delivered, not delivered (with the reason) or still running. For a job that is still running, ask the assistant to check on it, and watch its status:

The platform retries failed jobs, so a job that reported a failure can later report Complete once the underlying problem is fixed.

When a record didn't arrive, the assistant also says which of two things happened: the destination was reached and declined the record, which usually means a filter, or the destination was never reached, which on a sync into iPaaS.com often means the source had nothing to send.

How you check depends on the direction:

If the job completed but the record didn't arrive or change, the usual causes are:

A record can fail to arrive without raising an error. The most common reason is a mapping collection filter that skips it silently. Ask the assistant to review the mapping collection for that data type and direction, and to explain what its filter does. Also check that the integration supports that data type and direction at all, and that webhooks and polls are set up to send it. Note that a manual resync ignores whether a webhook is enabled, so a manual resync working doesn't prove the automatic sync will.

Anything else: mcp@ipaas.com.