The “Record & Replay” Lie: Why Traditional ERP Test Automation Is a Debt Factory

There’s a word that gets misapplied almost every time someone talks about ERP testing: automation.

When a D365 team records task interactions with RSAT, they call it automation. When an RPA team builds a UiPath bot that navigates a Business Central screen, they call it automation. When a low-code platform captures click sequences and replays them, they call it automation too.

It isn’t. Not really. What they’ve built is a script that will work exactly once, in exactly the state the screen was in when it was recorded. The moment Microsoft ships an update, which happens in April, in October, and in the service updates between, that scripts becomes a liability. And then another. And another.

That’s not automation. That’s technical debt with a test suite label on it.

What you’re actually Building When You Record a Test

Task recordings, selector maps, and UI scripts all share the same fundamental architecture: they capture the exact state of a screen at a specific point in time and encode instructions for replicating that interaction. The moment that state changes, a button renamed, a field moved, a workflow step added, the instruction becomes invalid.

For a consumer web app that releases once a quarter and has a stable UI, this is a manageable problem. For D365 Finance & Operations or Business Central, it is a structural one.

Microsoft doesn’t change D365 occasionally. It changes it continuously. Wave 1 (April) and Wave 2 (October) each introduce hundreds of UI modifications, new required fields, restructured forms, and updated business logic. Every one of those changes is a potential script failure. The regression suite you built last quarter is partially broken right now, most teams just don’t know which parts yet.

The Regression Rent You Pay Every April and October

Here is what the total cost of a recording-based ERP test suite actually looks like when you run it through a full release cycle:

Wave preview drops. QA team opens the test suite. Roughly 40–60% of recordings fail, the exact percentage depends on how broad the Wave changes are, but it is never zero. Someone is pulled from feature work to investigate which scripts broke and why. The fixes are mechanical, re-record the affected interaction, update the selector, adjust the hardcoded field reference, but they take time. Developer time. The same time that should be going into release validation.

This is what I call regression rent. You don’t own a test suite. You lease it from Microsoft, and the rent is due in April and October every year. The more scripts you have, the higher the rent. The more complex your D365 environment, the more expensive each payment.

And unlike real assets, a script suite doesn’t appreciate. It doesn’t get more valuable over time. The only direction is maintenance cost up and engineering time down.

Why Self-Healing Became Non-Negotiable in 2026

The industry response to brittle scripts has been ‘self-healing automation’, tools that detect when an element has moved and try to find it in its new location. It’s a genuine improvement over pure selector replay. But most implementations of self-healing are, charitably, selector retry with better marketing.

Real self-healing for ERP doesn’t fix a locator. It understands the workflow. When Wave 1 2026 reorganized the vendor payment journal in D365 Finance, a self-healing tool that re-identifies a moved button has helped with approximately one step of approximately one workflow. The team still needs to verify that the payment posted to the correct GL account, with the correct financial dimensions, in the correct period, none of which is visible in a DOM element.

Wave 1 2026 makes this even more acute. Business Central now ships with autonomous AI agents, Payables agents, Sales Order agents, that act on behalf of users. You cannot test an AI agent by replaying the UI interactions that triggered it. You have to validate the decision it made.

Stopping the Debt Cycle: Workflow-Level Adaptation

The alternative to recording-and-replaying UI interactions is understanding what the process is supposed to accomplish, and validating whether it did, regardless of which specific UI path was taken to get there.

A test built on process intent doesn’t break when a button is renamed. It doesn’t break when Microsoft adds a required field. It doesn’t break when Business Central’s AP Agent processes an invoice differently than a human would. It validates the outcome, the GL entry, the financial dimension, the inventory update, the order accuracy, and it does this across every Wave, every transport, and every configuration change.

This isn’t a marginal improvement on recording-and-replay. It’s a different model of what ERP test automation is. One that stops accumulating debt with every Microsoft release, and starts building test coverage that is durable precisely because it is coupled to the business process, not to the UI state.

Regression rent ends when the thing being tested is the outcome, not the click.