Integration failure, alert and retry
Inspect a configured contact sync that fails with HTTP 503, records the error for its owner, then succeeds after a requested retry. Delivering the same source record again updates the same contact.
HTTP failure → owner alert → retry → one contact
Inspect a configured contact sync that fails with HTTP 503, records the error for its owner, then succeeds after a requested retry. Delivering the same source record again updates the same contact.
| Workflow step | What you can see |
|---|---|
| Visible status | Failed on HTTP 503 → owner requests Queued → Succeeded on HTTP 200 |
| Owner and permitted retry | Assigned team member requests the retry; the unrelated purchaser cannot write this private project task. |
| Delivery evidence | Failure notification 12 and success notifications 13/14: native inbox, Sent. Recipient details show Delivered. |
| Duplicate check | External key DEMO-CONNECTOR-CUSTOMER-001: created contact 96, then updated contact 96; one matching record. Single-host worker lock tested. |
1 · Actual source failure and responsible owner
When a connection fails, give the responsible team a clear status and a next action. This example shows a failed request before a retry.
2 · Owner requests retry; source recovers
The assigned user moves the native task to Queued, then runs the configured worker after the source is restored. HTTP 200 creates contact 96. The native task shows Succeeded, the source key and exactly one matching company record.
3 · Repeat delivery updates the same record
A second successful delivery of DEMO-CONNECTOR-CUSTOMER-001 updates contact 96; the matching count remains one. The configured single-worker lock also rejects a simultaneous second worker. This tests repeat delivery within this connector scope, not every provider or distributed worker deployment.