Dynamics 365 UAT: a practical guide

When you need a UAT in Dynamics 365

A user acceptance test answers one question: can the business do its work in this version of Dynamics 365? The people who do the work test it, in their own words, before it reaches production. You need one at these moments.

• A go-live. The first Dynamics 365 Sales or Customer Service, or a move from another CRM.
• A new app or module. Customer Service next to Sales, a new model-driven app for a team, a customer portal, or Copilot features you switch on.
• A big change. A new integration with the ERP, or a new way of routing cases.
• The updates from Microsoft. Microsoft no longer bundles Dynamics 365 changes in two release waves a year. New features and changes roll out all year. The release plans were archived in October 2026; what is coming is now in the Microsoft roadmap at aka.ms/AIatWorkRoadmap. Any update can change how your system works, even if you changed nothing yourself.

A go-live needs a full UAT. The updates need a shorter regression test of the processes that matter most, on a fixed rhythm. More on that under After the go-live.

Environments

Never test in production. In the Power Platform admin center, every environment has a type. For a UAT you want a sandbox.

A copy of production

The closest you get to real life is a copy of production in a sandbox environment. When you copy an environment, you choose what comes along:

• Everything: the customisations, the schema and all data. Closest to production, but it holds real customer data and every record your users made.
• Customizations and schemas only: the configuration without the data. You load your own test data afterwards.

A copy replaces what is in the target environment, so make it before the UAT, never during it. Afterwards, point integrations and Power Automate flows to test systems, not to production, check the mailboxes, and take the environment out of administration mode when it is ready.

Solutions and the build

The changes of the project reach the UAT environment as solutions. Import them as managed solutions, through a pipeline if you have one, so the UAT environment gets exactly what production will get later.

• Agree when solutions are imported while testing goes on, for example once a day after the triage. An import in the middle of a test can change the screen under a tester.
• Write down which solutions and versions are in the UAT environment. The version number of a solution is the build you test, and every issue and retest belongs to one.

Test data

Testers lose hours when the data is not ready. Prepare it before the first test day:

• Accounts and contacts for each type of customer you test, with the right owner and business unit.
• Products and price lists. A product needs a price list item before it can be added at the right price, and it has to be published before sales reps can use it. Check that the price list of each sales team is there.
• Queues, SLAs and knowledge articles for Customer Service: the queues cases are routed to, active SLAs, and published articles to find.
• Open records to work on: leads, opportunities in different stages and open cases.
• No real personal data where you can avoid it. A copy with Everything holds all of it, so mask or anonymise what testers do not need to see.

Security roles, business units and users per role

A UAT proves that each role can do its work, and only its work. In Dynamics 365 that depends on the security roles, the business unit and the teams of a user. Apps are shared through security roles too: without the right role, a user does not even see the app.

• List the roles you test, such as a sales rep, a sales manager, a service agent and a service supervisor, with their business unit.
• Give each tester a user with exactly that role in the UAT environment. Every user needs a licence, in a sandbox too.
• When one person tests several roles, use a separate test user per role, or change the role between tests and write down which one was used.
• Never test with the System Administrator role. It sees and may do everything, so it hides exactly the problems a UAT should find.

What to tell testers about the environment

• The address of the UAT environment. The usual bookmark opens production.
• Which app to open, such as Sales Hub or Customer Service workspace, and which account to sign in with.
• That the data is test data: nothing they do reaches a real customer, and nothing they see is current.
• Who to call when they cannot sign in or do not see the app.

In UAT StudioEach tester gets a Test role, such as the security role, and a Test account, shown at the top of their tests as Log in as …. The Notes for testers hold the address of the environment, test mailboxes and who to call. Testers sign in to UAT Studio with a code by email, or with Sign in with Microsoft.

Test cases from user stories and processes

Start from the processes of the business, not from the tables in Dataverse. Two processes cover most of a Dynamics 365 UAT:

• Lead to opportunity to quote. A lead comes in and is qualified into an account, a contact and an opportunity. The opportunity follows the business process flow, gets products from the price list, a quote is made, approved and activated, and the deal is won and goes to the next team or system.
• Case management. A case comes in by email or through the portal, is routed to the right queue or agent, follows its SLA, is solved with a knowledge article, escalated when needed, and resolved.

Cut each process into test cases of one business scenario each, such as Qualify a lead with an existing account. Then check that every user story in scope has at least one test case.

Business process flows

A business process flow guides users through stages, with steps that can be required before the next stage. Test it as a user does:

• Every stage, and what happens when a required step is empty.
• Each branch, and each role: a flow can be switched on for some security roles only.

Routing, SLAs and knowledge

In Customer Service, much of the work happens without a click. Test what the system should do by itself: an email becomes a case for the right account, the case lands in the right queue, the SLA shows the right time and warns before it runs out, and the agent finds the right knowledge article.

Steps business testers understand

Write each step as an action and an expected result, in the words of the tester. Add test data where it matters. A tester should never have to guess whether a step passed.

Priority and risk

Not every test case is equally important. Mark each one Must, Should or Could: Must is what has to work on day one, such as making a quote or routing a case. Add the risk: what it costs when this goes wrong after go-live. Testers start with Must and high risk, so the important tests are done even when time runs out.

Add the unhappy paths too: a required field left empty, a discount above the limit, a user in another business unit who should not see a record.

In UAT StudioImport your test cases from Excel with the columns Priority and Risk, read them from Azure DevOps Test Plans, or start from the Dynamics 365 scripts in the template library, an add-on to every paid plan. With AI test design, AI proposes test cases from your user stories in Azure DevOps, also on your company's own model, such as Microsoft Foundry / Azure OpenAI. Nothing becomes a test case until you approve it.

Testers

Choose people who do the work every day: account managers, service agents, and their managers for approvals, queues and dashboards. Take testers from every team and country that uses Dynamics 365, because their processes, business units and price lists differ.

How much time

Agree the time per tester with their manager, and keep time for retests. Testers who are still taking calls or visiting customers will not finish.

A kick-off

Start with a short kick-off: why their test matters, how to open the UAT environment, how to record a result and how to log an issue. Let every tester sign in once during the kick-off and open the app. Most problems with licences, roles and the wrong environment show up there, not on the test day.

One test day or a week

One test day gives focus and quick answers, and suits a small scope. A week in blocks of a few hours leaves room for new builds and retests, and suits a go-live with many processes. Either way, fix a time for the triage every day.

During the UAT

Logging issues

A good issue can be fixed without a meeting. Ask testers for:

• The step, what they expected and what happened instead.
• A screenshot of the page, with the error message if there was one.
• The link to the record. It is in the address bar of the browser and takes the consultant straight to the opportunity or case where it went wrong.
• The user and the security role they tested with.

In UAT StudioThe browser extension for Chrome and Edge shows the tests in a side panel next to Dynamics 365. A failed step takes the screenshot, the link to the record and the error messages of the page along. The role of the tester is shown next to their name on the issue.

Triage

Go through the new issues every day, with the business and the Dynamics 365 team together. Give each one a severity and someone who fixes it, and decide:

• Fix: a real problem, fixed in this release.
• Reject: Dynamics 365 works as designed, or the test was wrong.
• Change request: a wish, not a defect. It goes to the backlog, not into this release.

Send the issues to fix to the developers, often in Azure DevOps, with the screenshot and the record link.

Retest

When the fix is in a new build in the UAT environment, the tester who found the issue tests the step again. Write down which build each retest was done on. After a large fix, test the processes around it again too.

Daily status

Send the steering committee a short status every day: progress against the plan, open issues by severity, and what blocks. No surprises at the go/no-go meeting.

In UAT StudioThe triage runs on a shared screen with Fix, Reject and Change request. An issue becomes a Bug work item in Azure DevOps; when it is done there, the issue is Ready for retest and the tester gets an email. Each round keeps its release, build and environment. Microsoft Teams gets new issues, rounds and sign-offs in a channel.

Sign-off and go/no-go

The UAT ends with a decision by the business. Agree the exit criteria before the first test day, so nobody argues about them at the end:

• No Critical issue is open.
• Every Must test case has passed.
• Every open High issue has a workaround or a date for the fix that the business accepts.
• Every test case in scope has a result.

Who signs

The owner of each process signs off, such as the sales director for lead to quote and the head of customer service for case management. They choose: accepted, accepted with conditions, or rejected. Write down every condition, with who does it and by when. The steering committee then decides on the go-live.

What goes into the report

• What was in scope, and what was not tested.
• The results per process or team, and per priority.
• The environment, the solutions and the build that were tested.
• The open issues by severity, with the decision on each one.
• The sign-offs, with their conditions, and the known risks for the first weeks.

In UAT StudioSign-off per group: Accepted, Accepted with conditions or Rejected. By default, nobody can accept while a Critical issue is open. The go/no-go report is ready as a PDF or as slides when the last result is in.

Regression rounds on a fixed rhythm

After the go-live, the updates keep coming, all year, and each one can change a form, a flow or a permission. Your UAT test cases are the best regression test you have: they describe exactly what the business accepted.

• Choose a rhythm, for example a regression round every month or every quarter, and put the dates in the calendar of the testers now.
• Before each round, read the Microsoft roadmap and the messages for your admins, and note which changes touch your processes.
• Try features in preview or early access in a sandbox environment first, before they reach your users.
• Test the Must test cases again, and Should if there is time, with a few testers from the business.
• Log issues as in the UAT, and fix them before the change reaches your users.

In UAT StudioChoose Dynamics 365 as the CRM of the project. Start a regression round copies the test cases you choose from an earlier UAT, with their steps, test data and expected results: Must and Should, Only Must or All test cases in scope.

Free to use

For everything to arrange before, during and after the UAT, see the UAT checklist for a CRM go-live, also as a free Excel file. For what UAT Studio does for a Dynamics 365 UAT, see Dynamics 365 UAT.

Microsoft, Dynamics 365, Power Platform, Azure DevOps and Microsoft Teams are trademarks of the Microsoft group of companies. UAT Studio is not affiliated with or endorsed by Microsoft.