The HR director has chased three approvals, payroll has a cut-off looming, and someone has just noticed that a leave request still sits in draft because the workflow never reached the right manager. That sort of problem is exactly why user acceptance testing exists. It's the last practical checkpoint before go-live, where business users prove that the system works for the way the organisation operates, not just for the way developers built it.
In UK delivery work, I've seen UAT save teams from releasing software that passed technical checks but failed on ordinary tasks like leavers, changes of bank detail, or document approvals. The point isn't to admire the software. The point is to make sure people can do their jobs on day one.
What User Acceptance Testing Really Means in Practice
A bad go-live usually doesn't start with a system crash. It starts with one workflow nobody bothered to test properly. In HR, that might be a leaver request sitting in limbo, an approval going to the wrong manager, or a compliance step that exists in the design but not in the live process.
User acceptance testing is the formal exercise where real business users validate that a system meets business requirements before release. The accepted industry definition from ISTQB frames acceptance testing as formal testing with respect to user needs, requirements, and business processes to decide whether a system satisfies acceptance criteria. Practically, that means UAT is not a demo, and it's not a general usability chat. It's a controlled decision point where the business says yes or no.
Why UAT sits with the business, not the build team
The business owner makes the operational sign-off decision. That's the whole reason UAT exists as a distinct phase. Developers can prove that code works, but they can't sign off on whether the workflow fits payroll deadlines, HR policy, or approval chains.
A useful way to think about it is this. Technical testing asks whether the software behaves correctly. UAT asks whether the software behaves correctly for the people who will live with it every day. That difference matters in UK organisations because acceptance testing is tied to evidence, traceable scenarios, and real business processes, not informal approval.
Practical rule: if the tester can't explain the business outcome in plain English, the scenario probably belongs in system or integration testing, not UAT.
For UK organisations, the challenge is significant because the business population is huge, with around 5.5 million enterprises in the UK according to official business population estimates. That scale makes a weak acceptance gate expensive, even when the defect rate looks small in isolation. Modern UAT guidance also recommends aiming for an engagement rate above 75%, a feedback turnaround under 24 hours, and a defect rate below 5% during testing, which turns acceptance into something measurable rather than vague. Those thresholds are guidance, not law, but they are a decent marker for whether the cycle is under control.
How UAT Differs from System, Integration and Regression Testing
A lot of failed UATs happen because teams load the wrong kind of problem into the room. If you ask business testers to validate interface mappings, component logic, and edge-case regression in one pass, sign-off slows down fast. The cleaner approach is to keep each testing phase doing the job it was designed for.
The boundaries that matter
System testing is technical. It checks that the solution works as built. Integration testing checks that systems talk to each other properly. Regression testing repeats existing checks after a change to confirm nothing broke.
UAT is different. It confirms the solution supports real business processes, meets acceptance criteria, is usable by the intended audience, and is ready for production deployment. That distinction is why UAT should be the last gate before go-live, not a catch-all for every unresolved question in the project.
You can see the confusion in many projects. A consultant will spot a report mapping issue and want to fix it in the UAT session. An IT lead will want to inspect identity provisioning. The HR lead just wants to know whether a new starter can be onboarded without hand-holding. All three concerns are valid, but they don't belong in the same test question.
Business acceptance is about process fit. Technical verification is about correctness. Mixing the two creates noise, not confidence.
What belongs where
A simple filter helps.
- System testing belongs to technical behaviour, for example whether a screen saves data correctly.
- Integration testing belongs to handoffs, for example whether a record reaches the next system.
- Regression testing belongs to change control, for example whether an unchanged workflow still works after a release.
- UAT belongs to whether the business can run the process.
That separation matters in Dynamics 365 projects because HR teams often see one workflow as one outcome, while the technical team sees five separate subsystems. The more clearly you divide those responsibilities, the faster you get to sign-off.
The UAT Process from Planning to Sign-Off
The strongest UAT cycles I've run didn't start with test scripts. They started with a clear scope, a named owner, and a test environment that looked and behaved like the one people would use in production. Without that, teams spend their time debating whether a defect is real instead of proving whether the business can run.
Start with planning, not scripts
Planning means deciding which business processes matter, who will test them, and what counts as pass or fail. That sounds obvious, but plenty of projects jump straight to spreadsheets full of steps without first agreeing what is in scope. A UAT cycle gets messy when every stakeholder assumes their favourite scenario is automatically included.
The most defensible test cases come from real business processes. A production-like environment matters too, because UAT is supposed to reveal issues users will face at go-live, not hide them behind idealised data. Published guidance also recommends making sure business users can log issues easily, with results and defects captured in a structured way rather than scattered across email threads and chat messages.
Execute, log, retest, then accept
Formal acceptance testing is described as an end-to-end script that users repeatedly execute until issues are resolved and the system can be formally accepted. That iterative loop is the part many teams underestimate. One test run rarely tells the full story, because the first pass often exposes data issues, access gaps, or workflow assumptions that need correction before the same scenario can be proven again.
A sensible sign-off pack normally includes:
- Test cases linked to business requirements, so each scenario is traceable.
- Recorded execution results, including pass, fail, comments, and date.
- Defect logs with severity and owner, so unresolved issues can't be hand-waved away.
- Evidence of re-tests, which shows the issue was fixed and checked again.
- Formal written sign-off, not just a verbal nod on a call.
A clean UAT pack doesn't need to be pretty. It needs to answer one question clearly, can the business safely go live?
If you want a broader project structure around these activities, the implementation sequencing in this Microsoft Dynamics 365 implementation project plan is a useful companion reference.
Sample UAT Scenarios for Dynamics 365 HR Workflows
Generic UAT advice falls apart the moment HR asks, “What exactly are we supposed to test?” In Dynamics 365 HR projects, the answer has to map to the workflows people use every week. That means onboarding, leavers, and change-of-circumstances activity, not abstract test names that nobody in the business recognises.
New starter onboarding
A solid onboarding scenario should follow the route from offer acceptance through to day-one readiness. The tester should be able to prove that the record is created, the right checks are triggered, and the right people receive the right tasks in the right order. In practice, that means the scenario needs to reflect the actual HR process, not a simplified happy path.
A business owner might sign off this kind of scenario against criteria such as:
- The offer is recorded correctly with the right starter details.
- Right to work steps are triggered where required.
- The personal record is created accurately and matches source information.
- Day-one provisioning tasks are issued to the right teams.
Evidence should show the workflow trail, any generated notifications, and the completed record created in the system. If the process depends on another operational system or a document store, that should be visible in the pack too.
Leaver workflow
Leaver testing is where weak process design becomes obvious. A resignation needs to flow through notice handling, asset return, access removal, and final pay checks without leaving loose ends. If one of those steps is skipped, the business feels it immediately.
Acceptance criteria for a leaver scenario should confirm that:
- The resignation is captured on time and routed correctly.
- Notice-related tasks are generated for the relevant stakeholders.
- Asset return steps are visible and trackable.
- Final pay inputs are ready for payroll review.
This is the kind of scenario that benefits from being tested with realistic timing and status changes, not just a static screen walk-through.
Change of circumstances
The third scenario many teams forget is a change to address, bank details, or absence information. These are deceptively small changes, but they often trigger downstream checks, approvals, and notifications. If they fail, employees notice before anyone in IT does.
A practical UAT pack should capture the before state, the change submitted, and the resulting update in the HR record. The test should also prove that downstream consumers of the data, such as payroll or reporting, receive the correct version. For more context on the HR platform side, the Dynamics 365 HR overview is the nearest product-level reference point.
Integration Acceptance Criteria for Dataverse, Teams and Entra ID
HR systems rarely live on their own. In a Microsoft 365 environment, the workflow is only half the story. The other half is what happens once data moves through Dataverse, notifications land in Teams or Outlook, and identity or licence rules are enforced through Entra ID.
Dataverse and the data flow behind the scenes
If the HR application is built on Dataverse, UAT shouldn't stop at the screen the user sees. The acceptance criteria need to prove that data lands where it should, in the form that other business processes depend on. That includes checking whether the record created in HR can be retrieved, reported on, and used downstream without manual repair.
This is also where migration assumptions get exposed. If the data structure is fine in technical testing but the business user can't find, interpret, or update the record in the way they expect, the workflow still isn't ready.
Teams, Outlook and identity
Notifications are part of the user experience. If a manager doesn't receive the approval request in Teams or Outlook, the process feels broken even if the backend logic is sound. UAT should therefore include acceptance checks for event-triggered messages, especially where timing and visibility affect day-one operations.
Entra ID is just as important. Access, group membership, and licence assignment can all affect whether a new starter can use the system. If those controls are wrong, the HR team ends up doing manual workarounds, which defeats the purpose of the implementation.
The useful habit here is to define the acceptance result from the business point of view. Not “the API call succeeded”, but “the right manager received the right action and the new starter could use the system without admin intervention.”
If an integration changes what a user can do on day one, it belongs in UAT, not just in a technical handover.
For teams shaping the data side of the project, the data migration strategy guide is a sensible companion read because migration quality and acceptance quality usually fail together.
Roles, Responsibilities and Who Should Not Run UAT
Most UAT delays come from ownership confusion, not missing test cases. The business assumes IT is running the show. IT assumes the HR lead has already approved the scenarios. Meanwhile, nobody is quite sure who is allowed to say the system is ready.
Who does what
The business sponsor owns the business outcome and the final sign-off expectation. The UAT lead coordinates the cycle, keeps the timetable moving, and makes sure evidence is collected. Business testers execute the scenarios and report what they see. The IT lead handles environment readiness, access, and defect triage. The solution partner supports configuration questions and fixes. A compliance reviewer checks that policy or regulatory steps haven't been lost.
A workable RACI for Dynamics 365 HR is simple:
- Business sponsor, accountable for acceptance.
- UAT lead, responsible for coordination.
- Business testers, responsible for execution.
- IT lead, responsible for environment and access.
- Solution partner, responsible for defect resolution support.
- Compliance reviewer, consulted on control points.
Who should stay out of test execution
Developers, consultants, and architects shouldn't run the business acceptance scripts themselves. They can support, observe, and resolve issues, but if they drive the test, the exercise stops being genuine acceptance. The same goes for technical regression work. That's important because many guides blur UAT with customer demo activity or broad validation, which creates role confusion and weakens sign-off.
Business acceptance only means something if the business actually owns it.
The practical pattern is to keep IT close enough to unblock the environment, but not so involved that they end up answering on behalf of the testers. That separation preserves the value of UAT, especially in HR projects where the stakeholders have different priorities and very different definitions of “done”.
UAT Checklist and Sign-Off Template You Can Reuse
A reusable UAT pack should be boring in the best possible way. It should tell people what to test, what counts as a failure, and what needs to be signed before go-live. If the pack can't do that without a meeting, it isn't ready.
A simple reusable structure
Use four deliverables. First, a pre-UAT readiness checklist covering scope, access, test data, and named testers. Second, a test case template with ID, business process, steps, expected result, actual result, and evidence. Third, a defect severity matrix so everyone uses the same language for triage. Fourth, a sign-off form that records the decision, the date, and who approved it.
The thresholds that published guidance recommends are a useful control target, with engagement above 75%, feedback turnaround under 24 hours, and defect rate below 5% before sign-off. Those aren't universal laws, but they do stop a project drifting into “nearly ready” territory for weeks.
A strong UAT habit set looks like this:
- Treat UAT as a control gate, not a usability workshop.
- Prioritise critical defects first, and block sign-off until they're fixed or formally accepted.
- Require written approval, because verbal agreement gets forgotten.
- Keep evidence traceable, so the pack can stand up in review.
The best UAT cycles don't feel dramatic. They feel controlled, auditable, and specific. That's usually the sign the business is ready.
If you're planning a Dynamics 365 HR rollout, or your current UAT cycle is already slipping into spreadsheet chaos, phone 01522 508096 today or send us a message at DynamicsHub contact page. We'll help you turn the acceptance process into something the business can sign with confidence.
