diff --git a/content/feed/rollback-data-changes/index.md b/content/feed/rollback-data-changes/index.md new file mode 100644 index 0000000..bf6fb5f --- /dev/null +++ b/content/feed/rollback-data-changes/index.md @@ -0,0 +1,73 @@ +--- +title: 'Oops! Now You Can Roll Back Data Changes' +description: Despite all the checks in Data Controller for SAS®, sometimes the wrong updates get approved. Since v6.8, you can roll back to a previous version - with full audit history preserved. +date: '2026-08-20 09:00:00' +author: 'Data Controller' +authorLink: https://www.linkedin.com/showcase/data-controller-for-sas +tags: + - Announcements +previewImg: './rollback-trains-meme.jpeg' +--- + +# Oops! Now You Can Roll Back Data Changes + +Despite the MANY checks and guarantees in Data Controller for SAS®, sometimes it can happen that the wrong updates are approved and applied. + +Thankfully, since v6.8, it is now possible to **roll back** data changes to a previous state. + +## How it works in practice + +Behind the scenes, rollback is not a silent undo. It is a **first-class approval workflow** just like any other edit. When you choose to restore a previous version, the backend - via the [`%mp_stripdiffs`](https://core.sasjs.io/mp__stripdiffs_8sas.html) macro - reads the `MPE_AUDIT` table (or a custom `AUDIT_LIBDS` configured for the table) and computes every difference between the current state and the version you want to go back to. + +It handles all three change types: + +- **Deleted rows** are re-inserted with their original values. +- **Modified rows** are reverted to their previous values. +- **Added rows** are marked for deletion with `_____DELETE__THIS__RECORD_____="Yes"`. + +The computed differences are written to a new staging package in the approvals directory, complete with a CSV and a `macvars.sas` snapshot of the session context. A new `LOAD_REF` is generated, and the package is submitted via the standard `%mpe_loader` service - so it goes through the same edit-stage-approve workflow as any manual change. + +This means the rollback itself is **reviewable and approvable**. Nothing is applied silently, and the full audit trail is maintained: the reversion appears as a new load reference in `MPE_SUBMIT`, `MPE_REVIEW`, `MPE_DATALOADS`, and `MPE_AUDIT`, just like any other submission. + +## Security and access + +Not everyone can roll back everything. The `%mpe_checkrestore` macro enforces a strict access check before the restore service will run: + +- The load must actually exist and have been loaded (no rollbacks of unapproved submissions). +- The table must be configured with an audit table. +- The user must have `EDIT` access to the target table. +- If the user is not an admin, Row Level Security or Column Level Security rules on the table will block the restore. + +If access is denied, the service aborts with a clear reason - no opaque errors. + +## What this means for compliance + +Because the rollback creates a new, approved changeset rather than silently rewinding history, auditors can see exactly what was reverted, when, and by whom. The `MPE_AUDIT` table retains the record of every intermediate state, so nothing is ever truly lost. For tables where data integrity is critical - regulatory reporting, actuarial assumptions, steering parameters - this is the difference between "we have no idea what happened" and "here is the complete chain of custody." + +This feature works for all temporal-aware load types (`UPDATE`, `TXTEMPORAL`, and `BITEMPORAL`) and respects SCD2 validity windows. And the whole process is built on the same open-source macro library that powers the rest of Data Controller - so you can inspect, test, and audit the code itself. + +Full documentation is here: https://docs.datacontroller.io/rollback-data-changes/ + + + + diff --git a/content/feed/rollback-data-changes/rollback-trains-meme.jpeg b/content/feed/rollback-data-changes/rollback-trains-meme.jpeg new file mode 100644 index 0000000..71d977c Binary files /dev/null and b/content/feed/rollback-data-changes/rollback-trains-meme.jpeg differ