If you’ve been managing Dynamics 365 quality assurance for more than a year, you already know the frustration. A Microsoft release wave drops. You pull up your RSAT test suite. Half the recordings fail because a button moved, a label changed, or the layout shifted. Your developers spend the next two weeks re-recording tests instead of building. And you still live nervously.
This is not a one-time problem. It happens every April. Every October. And with every hotfix in between.
RSAT, Microsoft’s Regression Suite Automation Tool, was a reasonable solution when Dynamics 365 was simpler and release cadences were slower. In 2026, it’s a bottleneck. The teams moving fastest on D365 aren’t trying to fix RSAT. They’re replacing the model entirely: from task recordings that replay clicks to AI agents that understand workflows.
This post covers what RSAT does well, where it fundamentally breaks down, how it stacks up against Leapwork and Sofy AI, and what it actually looks like to move from script-based regression to autonomous D365 test automation.
What RSAT Does Well (and Where It Stops)
Let’s be fair to RSAT before we critique it. There are genuine reasons every Dynamics 365 team has tried it:
- It is free and ships with D365 Finance & Operations
- It integrates natively with Lifecycle Services (LCS) and Azure DevOps
- Task Recordings are familiar to anyone who has used D365 for more than a few months
- For simple, isolated, single-module tests in stable environments, it works
The core problem isn’t what RSAT is, it’s what it was designed to be: a playback tool. It records exactly which elements you clicked, in which order, in which UI state. It then replays those exact interactions. underlying Cognitive Architecture. Unlike traditional bots that execute a linear list of commands, an ERP agent operates through a ReAct (Reason + Act) loop.
“RSAT doesn’t understand your business processes. It understands your clicks. That’s a meaningful distinction when your ERP changes twice a year.”
The moment anything about that UI state changes, a field renamed, a step reordered, a new required field added by the wave, the recording breaks. There is no intelligence behind the test. It cannot adapt. It cannot infer that the process is the same even if the screen looks slightly different. It just fails, and waits for a human to fix it.
5 RSAT Limitations That Slow Down D365 Teams
These aren’t edge cases. They are structural limitations that surface on every team, every wave:
Figure 1: The five structural limitations of RSAT that compound with every Dynamics 365 release wave.
1. No Cross-Module or End-to-End Testing
RSAT tests one module at a time. A test script for Finance doesn’t know what happened in Supply Chain. A sales order test doesn’t know whether the downstream warehouse pick or invoice posting succeeded. The most critical D365 failures, the ones that cause real business impact, happen at module boundaries: a correctly-posted PO that creates a bad GL entry, a fulfilled shipment that doesn’t update inventory correctly.
RSAT’s architecture makes these cross-module scenarios impossible to automate. Which means your most important workflows have no automated coverage at all.
2. Task Recordings Break with Every UI Change
Microsoft’s release waves are designed to improve D365, but every improvement is a potential recording failure. A renamed field. A reorganized form. A new required step in an approval flow. RSAT has no mechanism to adapt. The test fails, a developer is pulled to re-record, and the cycle repeats.
Over time, this creates a dynamics 365 regression testing debt that compounds with every wave. The chart below shows what this looks like in practice over three years of releases:
Figure 2: Cumulative broken tests and regression hours across 6 release waves, RSAT-based approach vs. Sofy AI agents (illustrative model based on customer data).
3. Requires Technical Users to Maintain
Task recordings are created through the D365 UI, but maintaining them, organizing them into test suites, configuring them in LCS, and debugging failures all require developer-level access and familiarity. Business testers, QA analysts, and process owners, the people who know D365 workflows best, are locked out.
This creates a dependency bottleneck: QA timelines are gated on developer availability. When developers are busy with wave preparation or feature work, testing slips.
4. No Self-Healing or AI Capabilities
RSAT has no intelligence layer. It cannot observe that a button moved and find it in its new location. It cannot infer that two slightly different UI paths lead to the same business outcome. When something changes, the test fails, period. In a platform that ships hundreds of UI changes per year, this is a fatal design limitation for anything resembling continuous testing.
5. Limited Reporting and Analytics
RSAT test results are pass/fail at the script level. There is no coverage mapping, no way to know which business processes are tested, which are untested, or where the highest-risk gaps are heading into a release wave. ERP program managers and QA leaders are flying blind on actual release readiness.
RSAT vs. Leapwork vs. Sofy: D365 Test Automation Tools Compared
When D365 teams start looking for a RSAT alternative, Leapwork and Sofy are the two names that come up most often. Here’s how all three compare across the dimensions that matter for a D365 environment in 2026:
| Feature | RSAT | Leapwork | Sofy AI |
| Cost | Free (Microsoft) | Paid license | Paid license |
| Setup complexity | High (dev required) | Medium (low-code) | Low (no-code) |
| Self-healing tests | None | Partial | Full AI self-healing |
| Cross-module E2E | Not supported | Limited | Full cross-module |
| Wave release support | Manual re-record | Manual update needed | Autonomous re-validation |
| No-code test creation | No | Partial | Yes |
| AI workflow knowledge | None | None | Native , per module |
| Supported by | Microsoft | Leapwork ApS | Sofy.ai |
Leapwork is a meaningful step up from RSAT. Its visual, low-code interface makes test creation more accessible, and it supports a broader range of applications. But it still relies on UI-level automation, which means it still breaks when the D365 UI changes, just with a slightly lower cost to repair. It also has no module-specific understanding of D365 Finance, Supply Chain, or Sales workflows.
Sofy’s differentiation comes from a different architecture entirely. Rather than automating UI interactions, Sofy’s AI agents understand D365 business processes at the semantic level , what the process is doing, what data should flow where, and what constitutes a valid outcome. That understanding is what makes self-healing possible.
How AI Agents Solve What RSAT Can’t
The shift from task recordings to AI agents isn’t about adding a smarter recorder. It’s a fundamentally different model of what a test is.
RSAT’s model: a test is a sequence of UI actions that must be replicated exactly.
Sofy’s model: a test is a business outcome that must be validated, regardless of which specific UI path was taken to get there.
Figure 3: The core difference between RSAT task recordings and Sofy AI agents, what each one actually understands about your D365 environment.
This distinction matters for three specific reasons:
Self-Healing That Actually Works
When a D365 release wave changes a button label or reorganizes a form, Sofy’s agents observe the change, understand that the underlying process hasn’t changed, and adapt their test path automatically. The test continues to pass. No developer is pulled. No recording is re-created. This is what no-code Dynamics 365 testing looks like at scale , not just easy to create, but easy to maintain through change.
End-to-End Process Validation
Sofy agents aren’t confined to a single module. A Finance agent can validate that a purchase order posted correctly to the GL. A Supply Chain agent can confirm that a goods receipt updated inventory and triggered the correct AP entry. The test validates the business outcome across modules, which is where real risk lives in D365 environments.
Release Wave Preparation in Days, Not Weeks
Because Sofy’s agents self-heal and run autonomously, release wave preparation looks different. When Microsoft publishes a Wave preview (typically 30–60 days before go-live), teams can trigger their full Sofy test suite against the preview sandbox environment automatically. Results are available in hours. Edge cases are flagged. Remediation is targeted. There is no manual regression sprint, just a clear, data-driven picture of wave readiness.
Real-World Impact: From Manual Regression to Autonomous Testing
A mid-market manufacturing company running D365 Finance & Operations and Supply Chain Management started each release wave preparation with a manual regression sprint lasting 3–4 weeks, consuming two developer-weeks and one QA-week of effort. RSAT scripts covered approximately 40% of their critical business processes, with the highest-risk cross-module workflows entirely untested.
After migrating to Sofy’s Finance and Supply Chain agents:
- Process coverage expanded from ~40% to over 90% of critical workflows within 6 weeks
- Release wave preparation dropped from 18–22 developer-days to 3–5 days of automated execution
- Zero manual re-recording required across the next three waves, despite significant UI changes in each
- Cross-module scenarios , procure-to-pay, order-to-cash , validated for the first time
“The first time Sofy ran autonomously against Wave 2 2025 and came back with results in four hours instead of three weeks, our ERP director asked if something had broken. Nothing had broken. That was just what it looked like when the regression sprint went away.”
How to Transition from RSAT to AI-Powered D365 Testing
The good news: you don’t need to delete your RSAT scripts on day one. The transition works best as a parallel-then-replace model:
- Step 1: Identify your highest-risk untested workflows.
Start with the processes RSAT can’t cover: cross-module E2E flows, release wave impact scenarios, and any workflow that has caused a production incident in the past 12 months. These are your first automation targets.
- Step 2: Connect Sofy to your D365 sandbox.
Sofy connects to D365 without code installs or agent deployments. Most teams are live in the environment within a single business day.
- Step 3: Build your first agent test suite.
Start with one module, Finance, Supply Chain, or Sales, and build coverage for your 10–15 highest-risk processes. No scripting. No recording. Define the workflow outcome and let the agent handle execution.
- Step 4: Run your first autonomous wave validation.
Trigger your Sofy suite against the next Wave preview. Review results. Where Sofy covers it and RSAT doesn’t, retire the RSAT script. Expand from there.
- Step 5: Expand to full coverage over 2–3 waves.
Most teams reach full RSAT replacement, and significantly broader coverage, within 2–3 release wave cycles. The migration pays for itself in the first wave where the regression sprint doesn’t happen.
The Bottom Line
RSAT was the right tool for a simpler era of Dynamics 365. It gave teams a way to automate basic regression scenarios when D365 was less complex and Microsoft shipped changes less frequently. That era is over.
The teams winning on D365 quality in 2026 aren’t maintaining larger RSAT script libraries. They’re running AI agents that understand their business processes, self-heal through wave changes, and deliver release wave readiness in days rather than weeks. The dynamics 365 regression testing problem isn’t going to get smaller, it’s going to compound with every future wave.
The question isn’t whether to move beyond RSAT. It’s how quickly you can get there before the next wave lands.
| Ready to replace RSAT with something built for 2026? Sofy’s purpose-built D365 agents, Finance, Supply Chain, and Sales, give your team self-healing test automation, cross-module E2E coverage, and release wave readiness without a single line of script. Explore Sofy D365 Test Agents |
Frequently Asked Questions
As of 2026, Microsoft has not announced a deprecation date for RSAT. However, Microsoft has not added significant new capabilities to RSAT since its initial release, while D365 itself has grown considerably more complex. Most analysts and practitioners expect Microsoft to eventually replace RSAT with a more modern testing framework, but teams shouldn’t wait, the limitations are real today.
Yes. Sofy and RSAT can run in parallel against the same D365 environment. Teams typically use Sofy to cover the workflows RSAT cannot handle, cross-module E2E, self-healing regression, while winding down RSAT coverage incrementally.
Leapwork is a general-purpose low-code automation platform with D365 connectors. Sofy is purpose-built for ERP workflows, with dedicated AI agents for D365 Finance, Supply Chain, and Sales. That module-specific depth means Sofy understands D365 business logic, not just how to click through forms , which is what makes true self-healing and cross-module E2E testing possible.
No. Sofy is designed for no-code Dynamics 365 testing, business analysts, QA leads, and process owners can build and maintain test suites without writing scripts. Developer involvement is optional for CI/CD pipeline integration, but not required to create, run, or maintain D365 test automation with Sofy.
Environment setup typically takes less than one business day. Building an initial test suite for a single module, Finance, Supply Chain, or Sales, usually takes 1–2 weeks. Most teams have meaningful automated coverage running ahead of their next release wave within 4–6 weeks of starting.
