Short answer
What matters most
Use a stable source identity for each document and revision, reuse it on retries, and enforce it at the destination. After a timeout, recover the saved result or check whether the target write succeeded before retrying. Treat a corrected file as an explicit revision, not another attempt. When two submissions merely look alike but lack a shared source identity, route them for review instead of auto-merging.
Separate a retry from a second business document
Suppose a hypothetical finance team sends an invoice through a document portal. The automation extracts its fields and creates a CRM record, but the confirmation times out. The worker cannot tell from that missing response whether the CRM created the record, so a blind retry can create it again.
The buyer question is which identity and retry rule prevents a second write without hiding a corrected or genuinely new document.
Ask three different questions: is this the same processing attempt, the same submitted document, or merely a document with similar values? Each needs a different control. The flow below gives one source item and revision a durable key, then shows where a repeated event, uncertain write, or ambiguous match should go.
Use the guide to jump to identity design, target-system behavior, a worked invoice, or the release acceptance matrix.
Choose a stable identity before extraction
A retry key should identify one submitted document operation, not one worker attempt. Create it once when the item enters the workflow and carry it through extraction, review, and the destination write. If the source provides a durable submission ID, combine it with the source or document type and the revision when those distinguish separate business items. If it does not, assign and save an intake ID before starting downstream work.
Do not make extracted supplier names, totals, or invoice numbers the retry key by themselves. They may be missing or corrected, and different legitimate documents can share values. Treat similarity as a signal for duplicate review, not proof that two source items are the same record.
Keep the key and processing state with the job. After a timeout, first look up the target record by that identity or reuse the destination's idempotency feature with the same request key. If neither is available, reconcile the uncertain result before issuing another create. Do not promise system-wide exactly-once behavior when the workflow crosses independent services.
A timeout does not tell you whether the write happened
AWS's reliability article describes how a caller can lose the response after a side effect succeeds. It recommends an idempotent request identifier for safe retries and explains that recording the identifier and applying the mutation need an atomic boundary for the strongest guarantee. Treat that as a design principle to verify in your own storage and APIs.
Amazon Builders’ Library: Making retries safe with idempotent APIs (published January 15, 2021)Check what the target does with a repeated key
A durable key helps only if the destination treats it consistently. Some APIs accept an idempotency key and return the earlier outcome when the same request is repeated. Others support a unique external key or an upsert, which creates a row when none matches and updates one when a match exists. Those behaviors are not interchangeable: decide whether an existing row should be returned, updated, or held for review.
For example, Stripe's API v1 remembers the first result for an idempotency key and checks that a retry uses matching parameters. The documentation says keys can be pruned after at least 24 hours, so a delayed retry may need your workflow's own durable identity and reconciliation. Check the exact retention and semantics of the API you use; this is a Stripe-specific example, not a universal contract.
Native idempotency has a product-specific lifetime
Stripe documents key-based retries for its API v1, including replay of the saved response, parameter matching, and pruning after at least 24 hours. Keep a durable business key outside that request cache when a workflow can resume later or needs an audit trail.
Stripe API reference: Idempotent requests (checked October 12, 2026)An upsert may update an existing row
Dataverse documents alternate keys for identifying rows during data integration. Its upsert creates a row if the key is absent and updates a matching row if it exists. Use that native behavior only when an update is the correct response to a repeat; otherwise configure a create-only or review path.
Microsoft Learn: Use Upsert to Create or Update a Record (updated March 10, 2026)Walk through a hypothetical invoice retry
A hypothetical supplier invoice arrives through a portal with a submission ID. The workflow saves that ID and revision as the job key, extracts the fields, checks them against the team's rules, and waits for a person if a required value is unresolved. The approved CRM write uses the same stable key, and the job stores the resulting record reference.
Now imagine the CRM creates the record but its response is lost. The recovery path checks the saved job state and searches or retries using the same destination key before attempting another create. If it finds the record, it returns the existing reference and closes the job. If the outcome is still uncertain and no safe replay is available, it holds the item for reconciliation instead of guessing.
A corrected invoice is different from a repeated delivery. Treat it as a new revision and make the business rule explicit: update the existing draft, create a linked correction, or ask a reviewer. A separate upload with similar supplier and amount fields is only a duplicate candidate unless a trusted source identifier or reviewed business rule confirms the match. This example is hypothetical, not a client result.
A key needs an active, non-null uniqueness rule
Microsoft says Dataverse alternate-key indexes enforce uniqueness only after the key is active, and null values in key columns do not enforce uniqueness. When using a native key, check its state and require the identity fields your duplicate policy depends on.
Microsoft Learn: Define alternate keys to reference rows (updated August 11, 2025)Built-in duplicate rules have a defined scope
Dataverse's documented default duplicate-detection rules cover accounts, contacts, and leads; other record types need an appropriate rule. A native duplicate feature can help where configured, but verify that it covers the actual record type and the action you need to protect.
Microsoft Learn: Detect duplicate data using the Web API (updated January 1, 2023)Test the failure paths before enabling live writes
Use this acceptance matrix with the source-system owner and the person responsible for the CRM or ERP. It distinguishes a safe retry from an intentional correction and from a lookalike that still needs a human decision.
On a small screen, scroll the table to read every column.
| Scenario | Expected behavior | Release evidence |
|---|---|---|
| Same source key arrives again | Reuse the existing job state or result; do not start a second create. | Redeliver after success and confirm one target record and the same record reference. |
| Two workers claim one key | Only one worker owns the write; the other reads or waits on that job. | Run concurrent claims and confirm one downstream create. |
| Target write succeeds but times out | Look up or safely replay with the same key before another create. | Simulate a lost response and confirm recovery returns one record. |
| Corrected or lookalike document arrives | Apply an explicit revision rule; review uncertain business matches. | Test a correction and a legitimate similar invoice with different source IDs. |
Use the simplest control the systems support
Before building a custom duplicate layer, identify the stable source value and the destination behavior you need. If your portal, workflow tool, and CRM can preserve that key and enforce the correct create or update rule, configure and test those native controls. Custom engineering needs a named gap, such as an identity that is lost between systems, a retry path that cannot reconcile writes, or a review queue that lacks the context an operator needs.
My enterprise document-automation engagement shows a checked path from submitted documents through business rules into existing CRM and ERP systems; it does not establish that every document process needs custom deduplication. If you are deciding what should happen after a repeated upload or timeout, bring one representative flow to a conversation about your system.