Blog
What is RSAT in Dynamics 365 and How It Works
Published on
July 13, 2026
Pricing
Live Webinar: The Rise of Autonomous QA for the AI Era - Register Now
What RSAT is, how its Task Recorder toolchain works, where it breaks, and why the May 2027 deprecation deadline makes this a planning question now.
Every Dynamics 365 Finance and Operations team eventually meets the same problem. Microsoft ships updates on a fixed cadence, the business cannot stop those updates, and someone has to prove that order-to-cash, procure-to-pay and month-end close still work after each one.
RSAT exists to make that proof less painful.
Understanding what it does, how it fits together, and where its edges sit is the difference between a regression cycle that runs itself and one that quietly consumes a team.
RSAT, the Regression Suite Automation Tool, is Microsoft's native automation tool for validating business processes in Dynamics 365 Finance and Operations. It converts Task Recorder recordings into automated tests, stores parameters in Excel, and reports results through Azure DevOps.
Microsoft has marked RSAT for deprecation, with support ending after 15 May 2027, which makes understanding both its mechanics and its successors a planning question rather than an academic one.
Dynamics 365 Finance and Operations runs on Microsoft's One Version service. The platform updates continuously, with major release waves twice a year and regular service updates in between, and customers are required to stay within a small window of the latest version.
That cadence is the whole reason regression testing matters here. A configuration that posted invoices correctly last quarter can behave differently after an update touches a shared form or a downstream calculation. The risk is rarely the headline feature. It is the quiet break in a workflow that finance relied on without thinking about it.
Manual validation cannot keep pace with that rhythm. Re-running a full business-cycle test by hand before every update means either skipping coverage or slowing the release. RSAT was Microsoft's answer to that squeeze: give functional power users a way to automate acceptance testing without writing code.
RSAT is a desktop application that automates user acceptance testing for finance and operations apps. It sits at the business-cycle end of the testing spectrum, the layer concerned with whole processes rather than individual units of code.
A few points define its scope precisely:
Microsoft is explicit about what RSAT is not for. Unit testing belongs to the SysTest framework. Data integration testing belongs to the data management framework. Trying to force RSAT into those roles produces brittle tests and frustrated teams.
RSAT is not a single tool so much as the conductor of a small orchestra. Four Microsoft components work together, and the test only runs cleanly when each plays its part.
Everything starts inside Dynamics 365. A power user opens Task Recorder and walks through a business task exactly as a real user would: create a sales order, confirm it, generate the invoice, post to the ledger.
Task Recorder captures each interaction as a structured step. The output is a recording that documents the process and, crucially, can be replayed. Recordings work best when they stay short and focus on a single business task performed by one role, which keeps them readable and easier to maintain.
The recording is then saved to Microsoft Dynamics Lifecycle Services and attached to a process inside the Business Process Modeler library.
The BPM library is where business processes are catalogued and grouped. For regression purposes, teams typically build a dedicated library that holds only the business-critical scenarios that must survive every update. That library becomes the master list of what the organisation cares about protecting.
The BPM library syncs to Azure DevOps, where each recording surfaces as a test case inside a test plan and test suite.
Azure DevOps does the heavy lifting around storage, sequencing and reporting. Test cases can be ordered so that variables pass from one step to the next, which matters for chained processes such as creating, shipping and invoicing a single sales order.
Results, logs, screenshots and error messages all land back here after a run.
RSAT loads the test plan from Azure DevOps into a local working directory. Each test case gets its own folder holding the recording, the generated automation files and an Excel parameter file.
The Excel file is the clever part of the design. Test parameters are decoupled from test steps, so the same recorded flow can run with many different data sets simply by editing values in a spreadsheet. A functional analyst who has never seen a line of code can change a customer, a site or a quantity and produce a new test.
Execution is driven through the browser, with RSAT playing back the recorded steps against the test environment. When every case finishes, the result column shows pass or fail, and failures link straight to the offending step and its error message in Azure DevOps.
Getting RSAT running cleanly the first time depends on a checklist of prerequisites that is easy to skim and expensive to miss.
The essentials:
None of these are difficult in isolation. The friction comes from the fact that they span three Microsoft products and usually two or three different people, so a single missing role assignment stalls the whole chain.
For its intended job, RSAT does something valuable. It gives organisations a native, low-cost way to confirm that core processes survive Microsoft's update cadence, and it does so in a vocabulary functional teams already speak.
Its real strengths are consistency and integration. Parameterised Excel files mean a test behaves identically on every run, removing the human variance that plagues manual regression.
The constant link to Azure DevOps turns each run into an auditable record with step-level evidence of what passed and what broke. For teams committed to the Microsoft stack and focused squarely on finance and operations, that is a meaningful step up from a spreadsheet of manual test scripts.
The boundaries are where the planning conversation begins, and they are worth stating plainly rather than discovering during a release weekend.
RSAT replays recorded steps against the application. When an update shifts a control, renames a field or restructures a form, the recording loses its target and the test fails. The failure is not a real defect, but it still demands attention, and someone has to re-record or repair the flow.
Across a large suite, that maintenance becomes the dominant cost.
RSAT was built for finance and operations apps, Cloud POS and warehouse scenarios. Most real business processes do not stay inside those walls. An order that begins in a customer portal, flows through Dynamics 365 and triggers a third-party logistics system cannot be validated end to end by a tool that only sees the finance and operations layer.
Parameterising through Excel is elegant for simple cases and awkward for intricate ones. Multi-role, multi-entity scenarios with branching logic push the spreadsheet model harder than it was designed for, and the workarounds add their own fragility.
The most important limit is no longer technical. Microsoft has marked RSAT for deprecation, and support ends after 15 May 2027. Teams investing heavily in new RSAT suites today are building on a foundation with a known expiry date, which reframes the entire build-or-migrate decision.
Two forces are converging on D365 teams at once. Microsoft is embedding AI deeper into the platform through Copilot and agent capabilities, and development across the wider estate is accelerating as engineering teams adopt AI coding assistants. Software is being produced faster, changed more often and recombined in more ways than before.
AI makes software easier to create but harder to trust. More code arrives more quickly, with more variability in how it is implemented and more subtle drift from what was originally intended. The expensive failures in that world are rarely a single broken line. They are workflow breaks, the moment a customer cannot complete a claim, a purchase or an admission because two systems stopped agreeing.
Record-and-replay tooling struggles against that backdrop precisely because it anchors to interface structure rather than business intent. When the structure moves, the test breaks, and the maintenance spiral begins. The alternative is a generation of testing that understands what a process is meant to achieve and adapts as the surface beneath it changes.
Virtuoso QA is the trust layer for Dynamics 365 and the systems around it. As code velocity rises, it provides continuous verification that customer-critical workflows keep working, whatever changed underneath them.
What that looks like in practice:
Try Virtuoso QA in Action
See how Virtuoso QA transforms plain English into fully executable tests within seconds.
