A Run is an audit log, not a rollback point
The Runs page tells you what happened. It does not capture what was true before the run started. Recovery does not live inside DMM Infinity.
The Runs page is one of the most useful screens in the product: it shows every execution, who ran it, what moved, how long it took, what the action statuses were. Read it as audit. Do not read it as a snapshot.
Why this happens
DMM Infinity stores execution telemetry: counts, timestamps, action results, error messages where they happened. It does not snapshot target rows. There is no per-run "before image" of the data, because storing one would mean copying the entire target on every run — at the cost of disk, time, and surprise charges nobody wants.
Recovery, when you need it, comes from outside DMM Infinity: the Mendix database backup tooling, your cloud provider's point-in-time restore, or a snapshot you took yourself by running a Copy into a separate sandbox before the destructive operation. There is no fourth option.
What to do instead
Plan recovery before you need it. For any Copy that materially changes a production target, take a backup first — Mendix-side, cloud-side, or as a "snapshot" pipeline that copies the target into a sandbox environment. The records you spend on the snapshot count against your annual allowance, but a million records of insurance is cheaper than a single-record incident at the wrong moment.
- ·Snapshot the target into a sandbox before destructive runs, using a Copy with Insert into a fresh environment.
- ·Use database-level backups for time-bounded recovery windows on production.
- ·Treat the Runs page as audit: who, when, what, how many. Not as source-of-truth.
- ·Decide the recovery plan when you write the pipeline, not when something goes wrong.
- ·Rely on "I can just re-run it". Re-running with the same source produces the same result; it does not undo prior writes.
- ·Skip backups because the run "looked small" in the preview. Small in row count, large in business impact.
- ·Use the Runs page to plan recovery — by the time you are reading it for that reason, recovery has to come from somewhere else.
A concrete example
A Merge run from staging into production updated 3,400 Customer rows with stale source values — staging had been frozen for testing but the same staging environment was still pointing at the production-bound pipeline. The team noticed within an hour and tried the obvious recovery: run the same pipeline in reverse, from production back to staging, then again from staging into production.
That second run overwrote the same 3,400 Customer rows with the same stale values. Two successful runs in the audit log, identical outcome to the first one, no recovery. The actual fix came from the database-level backup taken six hours earlier — outside DMM Infinity, owned by infrastructure, restored manually.