Process automation
An outage leaves a gap in transferred transactions, but replaying the whole period could repeat finished work. Totals don't show which records are safe to recover. We compare individual records, agree on side effects, and process only reviewed missing transactions.
Discuss this problemWe start with the outage window and the last work confirmed in the receiving system. Stable references let us sort records into missing, changed, rejected, and already accepted. The review covers any messages or financial actions a replay might trigger. Your process owner approves the limited recovery list before anything runs. We check typical transactions first, then compare the results against the list. Any unclear match stays an exception with its supporting evidence, and nobody guesses it into the replay.
Source records exist for the outage period, but no matching accepted entry appears in the receiving system. The gap is obvious, yet its exact size stays unclear until someone compares each transaction's reference.
A proposed rerun includes records that already reached the receiving system. Repeating the period would mix finished work with missing transactions, and it could recreate messages, documents, or other actions.
Teams see a difference in totals but can't name the transactions that need recovery. A summary mismatch gives too little evidence to decide which operations can safely be repeated.
We compare outage evidence and source times with the last work the receiving system confirmed. The window includes delayed arrivals, so recovery doesn't accidentally miss work at either edge.
Next, we match stable transaction references and inspect what the receiving system accepted. That separates missing records from changed records, rejections, and work that succeeded before its confirmation failed to reach the connector.
We examine the side effects of replaying the affected operation. An old transaction can still send a message or release work, so those effects need an approved treatment before recovery begins.
We create a manifest, a written list holding only reviewed missing transactions and their intended destinations. Each entry keeps its source evidence and the business rule that applies to recovering it at this later time.
We recover batches you can watch, using supported duplicate controls and recorded outcomes. A typical test shows the behavior before a larger set runs, and rejected entries stay separate for review.
We compare accepted results with the approved manifest and the final state of the receiving system. Every listed transaction ends with proof of completion, or with a clearly marked unresolved exception and an owner for the next step.
No. Only records confirmed as missing should enter an automatic recovery list. A failure response can occur after the receiving system accepted the request, so we compare evidence from both sides first. That protects finished work from being repeated simply because it fell within an outage period.
We inspect the side effects of your specific replay route first. Your team approves how delayed messages should be handled before recovery. Some systems may need a supported notification control or a separate owner decision, so old messages don't go out as though they were new.
We look at other supported matching evidence and record unclear cases for review. Similar amounts or names alone may not show that two entries are the same transaction. If we can't show a reliable link, the record stays outside automatic replay until its owner resolves the uncertainty.
Name the source and receiving platforms and the approximate missing period. Share one transaction, with personal details removed, that is in the source but absent downstream, so we can work out the fields to match on.
Explore Process Automation More problems in Process automation
Tell us about your project and we'll get back to you within 24 hours.