Start with one workflow and one ambiguous failure. You need a decision about what to do after uncertainty, not a long list of apps to connect.
Trace a response that never arrived
In this original fictional workflow, an approved service request R17 should create exactly one help-desk ticket. The source delivers R17. The destination creates ticket T93, but the response is lost before the workflow records the ticket ID.
The workflow now knows that its request was sent and that no response was received. It does not know whether the destination accepted the write. Reporting "creation failed" would overstate the evidence.
| Event | Known information | Appropriate next state |
|---|---|---|
| R17 arrives for the first time | No completed operation is recorded | Begin the named create operation |
| Create request times out | Destination result is uncertain | Reconcile this operation |
| Destination confirms T93 belongs to R17 | The required record already exists | Record T93 and complete locally |
| R17 is delivered again | Same logical request, even if delivery ID differs | Reuse the same operation identity |
Microsoft's idempotency guidance, checked October 24, 2026, explains why repeated identical requests need duplicate handling and concurrency controls. It does not establish that any particular connector makes a ticket creation safe to repeat.
Keep operation identity stable across retries
Use a stable business request ID plus the operation and its version, for example R17:create-ticket:v1. A new timestamp or randomly generated retry ID would identify every delivery differently and defeat this duplicate check.
Ask what the real destination supports. A server-enforced idempotency key can help only under that service's documented scope, retention period and same-key behavior. If the destination instead stores a unique external request reference, confirm that it enforces uniqueness when two requests arrive together.
A separate "look up, then create" sequence can race: two workers both see no ticket and both create one. A local log written before the request can also leave an unfinished operation after a crash. The design needs an atomic claim or destination-side guarantee, a durable status and a way to reconcile incomplete work. A spreadsheet check alone is not an exactly-once guarantee.
Copy a recovery-design prompt
Design a reviewable workflow; do not connect accounts or enable it.
Business result and source request ID: [ENTER]
Trigger payload and duplicate-delivery behavior: [PASTE]
Destination create API/connector documentation: [PASTE]
Documented idempotency/unique-reference behavior and retention: [PASTE]
Permitted state store and concurrency guarantees: [ENTER OR UNKNOWN]
Approval boundary and human exception owner: [ENTER]
Map first delivery, repeated delivery, concurrent delivery, timeout
after destination success, crash before local completion, and permanent
validation failure. Keep the business operation identity stable.
For each state, show known facts, durable record, next action and how
to reconcile an unknown destination outcome. Identify atomicity needs.
Do not infer a write failed merely from a timeout. Do not invent a
connector guarantee, silently retry unknown writes, or promise exactly
once. Give a sandbox replay plan with expected destination record counts.
OpenAI's prompting guidance supports supplying the actual context and constraints. Paste the destination's documented behavior rather than asking the model to assume it from a connector name.
Rehearse the ambiguous cases
In a sandbox, replay R17 twice and inspect the destination records. Then simulate a lost response after the write and replay it again. The intended outcome is still one ticket associated with R17, with the workflow eventually recording that ticket's ID. Test concurrent delivery separately; sequential repeats do not expose every race.
Keep actual observations beside those expected results. If the destination cannot provide a safe retry or lookup path, route uncertain creates to the designated exception owner until the outcome is reconciled. Do not hide that limitation by increasing the retry count.
The project-planning guide helps assign the unresolved implementation decisions to real owners. Enable the operational flow only after those decisions and the sandbox results support its recovery behavior.