Dynamics 365 Integration / Field notes
When an F&O Create Request Times Out: Recover Without Duplicating the Record
A timeout tells the caller that it did not receive a response in time. It does not prove that Finance & Operations rejected the operation. Before sending a create request again, establish whether the first attempt produced a business record and define how the integration can safely identify it.
Treat a timeout as an unknown outcome
A request can reach the service and commit work even when the response is lost on its way back. If a client treats every timeout as a failed create and submits the same business operation again, the result can be two records or a validation conflict.
Separate transport state from business state. Record the request attempt and its stable business reference, then check the destination using the documented key or an approved status lookup before deciding whether another action is needed.
- Keep the source document ID and company context
- Record the attempt time and operation type
- Do not infer failure from a missing response
- Use an operator review path when the destination cannot be checked
Choose a reference that survives the handoff
A retry is useful only when the receiving workflow can tell whether it refers to the same business operation. Define a stable external reference or integration key and confirm how the Finance & Operations entity exposes and validates it. A generated identifier that changes on every attempt cannot identify a duplicate.
Natural or alternate keys must represent durable identity. If the key changes after the first exchange, the relationship can be broken; assign an owner and change policy to every cross-system identifier.
| Evidence | Question | Decision |
|---|---|---|
| Source ID | Does it remain stable across retries? | Reuse it for every attempt |
| Company | Which legal entity owns the record? | Carry it explicitly |
| Destination key | Can the record be queried by that reference? | Confirm entity and key behavior |
| Operation result | Was business processing completed? | Check status before replay |
Separate a safe replay from a duplicate create
A retry policy belongs to the operation, not just to the HTTP status. A read can generally be repeated without creating another business object. A create or posting operation needs a deduplication rule, a destination lookup, or an explicit business correction before another submission.
For service protection responses, Microsoft documents honoring the Retry-After interval on HTTP 429. That interval addresses when to send again; it does not by itself make a create idempotent. Keep those two decisions separate.
- Persist the request reference before sending
- Send once and store the returned result or timeout
- Check the destination by the stable reference
- Replay only when the operation contract makes it safe
- Route unresolved outcomes to a named review queue
Test the lost-response case deliberately
A happy-path test proves that a response can be received. It does not prove recovery when the response is lost after the destination has committed. Include that case in integration acceptance, alongside duplicate delivery, an invalid reference and a retry after a 429 response.
The business owner should be able to reconcile the source document to one destination record and see whether the integration needs action. Store only the diagnostic information needed for that decision, and keep credentials and unnecessary customer data out of logs.
Primary sources
Sources and further reading.
These platform references support the technical guidance. Available features, versions and implementation requirements should be checked against your environment.