A CRM request can time out after the remote system has created the record. The local application then has an unknown result. Retrying that create request immediately can create a second record unless the destination offers a suitable deduplication mechanism.
This guide proposes a retry policy for the unimplemented Workflow Inbox blueprint. The downloadable decision table has no executed results. The examples describe interface choices that must be confirmed against the selected CRM and account configuration.
Record the intended operation before sending it
Save an operation identifier, the approved payload revision and the destination account before dispatch. Keep the logical operation stable across transport attempts. The attempt number can change; the identity of the approved change should not.
Record when an attempt begins and preserve any returned destination identifier. If the connection ends without an authoritative response, mark the operation outcome unknown. A local timeout measures how long the caller waited. It cannot establish what the remote system committed.
HTTP specifies idempotence in terms of the intended effect of repeated requests. It cautions against automatically retrying a non-idempotent request unless the client knows the request semantics are idempotent or knows the original request was never applied. This is the starting constraint for a create-record retry policy. HTTP semantics.
Inspect the destination's actual identity mechanism
An endpoint may offer an idempotency key, an upsert operation or a unique external identifier. These mechanisms need separate review. Check how the provider scopes the key, how long it retains it and what happens if the payload changes. If those answers are absent, record the capability as unconfirmed.
Salesforce documents upsert by an external ID. No match can create a record, one match can update it, and multiple matches produce an error. Its updateOnly option changes the no-match behavior. These distinctions matter when a business rule allows updating a contact but forbids creating one. Salesforce external-ID upsert.
HubSpot documents contact upsert using email or a custom unique identifier. It also documents a restriction on partial upserts with email. Review the precise endpoint and payload rather than assuming every operation called upsert behaves the same way. HubSpot contact upsert.
| Destination capability | Proposed response to an unknown outcome | Remaining question |
|---|---|---|
| Documented idempotency key | Retry the same approved payload with the same key | Is the key still retained? |
| Unique external identity | Read or upsert using the agreed identity | Can repeated updates trigger other side effects? |
| Query with uncertain freshness | Reconcile before another create | How is absence established? |
| No reliable identity or lookup | Hold for manual investigation | Who resolves the remote record? |
Avoid turning a search miss into proof
Write down which query can confirm the remote result. Matching only a display name is usually too ambiguous for this design. Prefer the destination record ID when known, or the external identity that the request itself carried.
A lookup response also needs interpretation. An empty result is useful only if that lookup's visibility and consistency guarantees are sufficient. A caller with reduced permissions may see no record even though another account can see it. Preserve the lookup method and account in the investigation record so an operator can assess the evidence.
Use a unique local operation constraint to prevent two workers from independently dispatching the same logical change. PostgreSQL supports uniqueness across a combination of columns, which can represent a destination account plus operation identity. This constrains local records; it does not extend a database transaction across the CRM network call. PostgreSQL unique constraints.
Rehearse the failure window
The most useful proposed case interrupts the connection after the mock destination records a create and before the caller receives its response. The expected local state is unknown. The next step should follow the selected capability row, with evidence that only the intended remote record exists.
Also plan a crash after remote success but before the local success record, two concurrent retries and a payload edit while reconciliation is pending. The edited payload needs a new approval decision. Keep it out of an older operation's retry sequence.
Download the CRM retry decision worksheet and fill in the provider documentation, confirmation query and operator owner. Every test case remains Not run until an actual adapter or explicitly labeled mock supplies evidence.
The Workflow Inbox blueprint proposes a visible exception queue around this workflow. Bring the exact destination endpoints before agreeing that retry behavior is included in a custom implementation.
