Practical guide

Queued, missing and failed integrations need different recovery

Last materially reviewed 2026-09-23

Quick answerCheck the existing request and destination state before retrying an uncertain handoff.
What to know

Separate the failure states

A destination record that has not appeared yet can mean the handoff is pending, the event did not trigger, a mapping failed or the destination rejected it. These are different diagnoses. The involve.me troubleshooting guide distinguishes pending and error conditions and discusses timing, but its examples are not a guaranteed delivery service level. Record what is actually visible rather than treating a short delay as proof of failure or a success label as proof that every required field arrived.

What to know

Diagnose the event and field requirements

Compare the completed source event with the configured integration trigger. Then inspect required fields, relevant permission or opt-in mappings and the target record structure. Do not disable privacy choices simply to force a test to pass. The documentation also warns that a newly connected integration does not automatically imply historical responses have been replayed. Establish the actual supported behavior before promising that old requests will appear in the destination without further authorized work.

What to know

Verify before retrying

If the original outcome is uncertain, inspect both the source response and destination before sending again. A blind retry can create duplicate contacts or tasks even when the first request eventually succeeds. Preserve the original request identity and the evidence of each action. When an exact repair is justified, test only that change with a harmless sample and verify the received fields. Do not call an integration complete because the account connection itself succeeded.

What to know

Keep a bounded fallback

A manual handoff may be appropriate if an authorized person can retrieve the required response safely and the duplicate risk is understood. Do not export all customer data merely to recover one uncertain request. Document what was transferred, which existing record it belongs to and what still needs verification. Complex replay or synchronization behavior requires a separately established contract; a simple calculator publication should not invent infrastructure or reliability guarantees that the product evidence does not support.

Continue when useful

Next: Give the next owner a usable estimate record

Keep the relevant inputs, estimate assumptions and requested next action together.

Open Give the next owner a usable estimate record →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Integration not triggering or sending — Merchant documentation · help.involve.me · Merchant-controlled · checked 2026-09-23
  2. Participant results and analytics — Merchant documentation · help.involve.me · Merchant-controlled · checked 2026-09-23