User acceptance testing for Dynamics 365
Running an effective UAT cycle on Dynamics 365 — scenarios, environment, exit criteria, and what to test that's actually worth testing.
User Acceptance Testing (UAT) is the customer's chance to validate that Dynamics 365 — configured, customised, and integrated — actually does what their business needs. Done well, UAT catches the painful gaps before go-live; done badly, it confirms what the demo already confirmed and gives false confidence.
The point of UAT. Not to test that the software works (Microsoft and the partner already did that). To test that the business processes, end-to-end, in this customer's specific operational context, with this customer's data and integrations, produce the expected results.
Scenarios over screens. Build UAT around real business scenarios, not feature lists. A scenario reads like: "Process a customer order from quote to invoice for a customer in Sweden, with a discount, drop-shipped, paid 30 days net, intrastat-relevant." Each scenario crosses multiple screens, modules, integrations, and roles — and is what fails when something's wrong.
Coverage. Aim for:
- 100% of core operational scenarios (order to cash, procure to pay, period close, payroll, etc.).
- All workflow paths, including rejection and rework.
- All integration points, with both happy and unhappy paths.
- Critical reports run with real-looking data.
- Edge cases the customer's industry / region demands (e.g. country-specific tax filings).
Environment. UAT runs in a dedicated sandbox copied from production-ready configuration with realistic data volumes and all production integrations connected to test endpoints. Testing against an empty demo company is theatre, not UAT.
Real users. UAT is run by the people who'll use the system, not by IT and not by the partner. The salesperson tests the sales process. The AR clerk tests AR. The shop-floor lead tests production reporting. If users are too busy for UAT, they'll be too busy to use the system after go-live.
Scripts vs exploration. A blend works best: scripted scenarios cover the must-have flows; exploratory testing for half a day per user catches the edges no script anticipated. Both feed the defect log.
Defect management. A clear bug-tracker — Azure DevOps, Jira, or simple in the partner's PSA — with severity, priority, status, and owner. Triage daily. Severity 1 (showstopper) and 2 (workaround painful) must close before go-live; lower severities can ship to backlog.
Exit criteria. Before declaring UAT complete, the business signs off:
- All scenarios executed.
- All sev 1 / sev 2 defects resolved or formally accepted.
- Performance acceptable at expected user load.
- Training material aligned with what users tested.
- Integrations operating end-to-end at scale.
What UAT isn't. It isn't a substitute for the partner's earlier system, integration, and performance testing. By the time UAT starts, those tests should be green. UAT is the business confidence check.
Related guides
- Budget management for Dynamics 365 implementationsHow to budget and manage costs for a Dynamics 365 project — cost categories, tracking discipline, change control, and the patterns that prevent budget overruns.
- Business process mapping for Dynamics 365How to map business processes for a Dynamics 365 implementation — process hierarchies, BPMN notation, scenarios, and the patterns that produce useful process documentation.
- Change management for Dynamics 365How to run change management on a Dynamics 365 implementation — stakeholders, comms, training timing, and the cultural patterns that decide adoption.
- Change readiness assessment for Dynamics 365 implementationsHow to assess organisational readiness for a Dynamics 365 implementation — readiness dimensions, surveys and interviews, gap analysis, and the interventions that close gaps before go-live.
- Cutover planning for Dynamics 365How to plan the production cutover for a Dynamics 365 implementation — the cutover playbook, data migration windows, parallel running, and the high-pressure days around go-live.