UAT Testing for Dynamics 365 CRM: A Practical Guide

Dynamics 365 CRM implementations fail differently to ERP implementations. The technical configuration might be perfectly sound: workflows triggering correctly, integrations connecting, security roles in place. And then the sales team uses it for two weeks and stops logging in. The problem was never the technology. It was that nobody validated whether the system matched how the team actually sells.

This guide is for the consultants and project managers running Dynamics 365 CRM implementations. It covers what to test in D365 Sales, Customer Service, and Field Service, how CRM UAT differs from Business Central UAT, and how to get sign-off from the one stakeholder who can make or break your go-live: sales leadership.

1. Dynamics 365 CRM vs Business Central UAT: Different Users, Different Risks

If you have run UAT on a Business Central or SAP implementation, your instinct will be to bring the same structured approach to a D365 CRM project. The same disciplines apply: clear test cases, defined pass criteria, a proper sign-off process. But the nature of what you are testing is fundamentally different.

Business Central is used by finance and operations staff who run structured transactional processes. There is a right way to post a purchase invoice. Either the VAT is correct or it is not. Either the GL entry lands on the right account or it does not. Pass/fail is usually clear.

Dynamics 365 CRM is used by sales reps, customer service agents, and field engineers. Their workflows are less structured and far more judgment-driven. A sales rep navigating an opportunity record does not have a "Post" button that produces a verifiable ledger entry. Success looks like: does this view help them prioritise their pipeline? Does this activity log give their manager visibility without adding 20 minutes to their day? These are subjective judgements that only the people doing the job can make.

This makes CRM UAT harder in a specific way: you cannot write a test script that definitively passes or fails. You need your users to genuinely engage with the system, and you need to create the conditions where they will give you honest feedback rather than just clicking through and signing whatever you put in front of them.

2. What to Test in Dynamics 365 Sales

D365 Sales is the core CRM module for most implementations. Testing should follow the actual sales process from lead generation through to closed deal, not the system menu structure.

Lead and Opportunity Management

• Lead creation and qualification: create leads from multiple sources (web form, manual entry, import), qualify them to opportunities, and validate that the conversion process creates the correct account, contact, and opportunity records. Disqualification flows also need testing: what happens to leads that are lost or duplicated?
• Pipeline stages: validate that the opportunity stages in the system match the actual sales process. This is where many implementations go wrong. If the stages were defined by the project team rather than the sales team, they will not reflect reality. Test that stage progression is intuitive and that the probability weighting at each stage makes sense for pipeline reporting
• Win/loss recording: close opportunities as won and lost. Verify the data is captured correctly for later reporting. Check that lost reasons are mandatory and that the options in the list are meaningful to the team, not just generic dropdown values

Quote Generation and Approval Workflows

• Quote creation: if D365 Sales is being used for quoting, test the full quote-to-order flow. Add products from the product catalogue, apply pricing and discount rules, and generate the quote document. Validate that pricing logic works correctly for tiered pricing, customer-specific pricing, and promotional rates
• Approval workflows: if quote approval is required above a certain value, test the Power Automate flow from quote submission through manager review to approval or rejection. Test the rejection path: does the rep receive the right notification, and can they amend and resubmit?
• Quote to order conversion: validate that converting a quote to a sales order retains all relevant data and triggers any downstream processes correctly, including integration with Business Central or another ERP if applicable

Account and Contact Data Quality

• Account hierarchy: if your business uses parent/child account structures (e.g., a group company with multiple subsidiaries), validate that the hierarchy is correct and that relationships between accounts render properly in views and reports
• Duplicate detection: test the duplicate detection rules. Create an account that matches an existing record and confirm the system flags it correctly. This is particularly important after data migration, where legacy data often contains genuine duplicates
• Contact associations: validate that contacts are correctly linked to accounts, that contact roles on opportunities work, and that the relationship mapping reflects how your team actually tracks stakeholders in a deal

Activity Logging

• Calls and meetings: log a phone call, a meeting, and a task against an opportunity. Verify they appear in the activity timeline in the correct order and with the correct details. Check that activities are visible to the sales manager without the rep needing to do anything extra
• Outlook integration: this is one of the highest-risk areas in any D365 Sales UAT. Test that tracked emails from Outlook appear correctly in D365. Test with multiple email clients (Outlook desktop, Outlook web app). Test what happens when a rep sends an email from a personal address or uses CC/BCC. The Outlook integration breaks in subtle ways for different user configurations and must be tested on real devices with real accounts
• Teams integration: if Teams meeting integration is in scope, test that meeting records are created in D365 and linked to the correct account or opportunity. Validate that post-meeting notes or action items can be captured within the Teams interface if that workflow has been configured

Dashboards and Views for Sales Managers

• Pipeline views: have the sales manager review their pipeline dashboard with real data (from migration or test data that reflects actual deal volumes). Does the pipeline value look correct? Are the funnel stages showing the right deal counts? Can they drill into individual opportunities from the dashboard?
• Activity reporting: managers need to see team activity without asking each rep individually. Validate that the team activity views show the right data and that security roles prevent reps from seeing each other's full pipeline unless that is deliberate
• Forecasting: if the D365 forecasting module is in scope, validate that forecast categories map to the opportunity stages correctly and that rollup calculations produce meaningful numbers

3. What to Test in Dynamics 365 Customer Service

If Dynamics 365 Customer Service is in scope alongside Sales, plan for a separate UAT phase with your service team. The workflows are distinct enough that trying to run Sales and Customer Service UAT concurrently with the same group of users usually produces shallow testing of both.

Case Creation and Routing

• Case creation from multiple channels: create cases manually, via email-to-case, and (if configured) via web form or Teams. Verify that subject, priority, and category are captured correctly from each channel and that the case owner is assigned correctly by routing rules
• Routing rules: test that cases route to the correct queue or agent based on your configured rules. Test edge cases: what happens when the assigned agent is out of office? Does the escalation path fire correctly?
• Case resolution and closure: resolve a case and validate the resolution is recorded. Test re-opening a case that was closed prematurely and verify the audit trail reflects the re-open correctly

SLA Timers and Escalation Paths

• SLA configuration: validate that SLA timers start correctly when a case is created or updated. Check that the SLA applies the right business hours calendar and that timer pausing (for waiting on customer responses) works as expected
• Escalation alerts: trigger an SLA warning by leaving a test case open past the warning threshold. Confirm that the agent and supervisor receive the right notifications. This requires patience in testing but is critical: SLA failures in production are embarrassing and sometimes contractually significant

Knowledge Base and Queue Management

• Knowledge article linking: search for a knowledge article from within a case and link it as the resolution. Validate that the article is readable, correctly formatted, and that agents can send it to the customer directly from the case
• Queue views: have agents test their queue views with realistic volumes of cases. A queue view that works with five test cases may be unusable with 200 real cases if sorting, filtering, and colour coding are not configured correctly. Test with data volumes that represent a busy day

4. What to Test in Dynamics 365 Field Service

Field Service UAT is the most operationally complex of the three D365 CRM modules. You have office staff, dispatchers, and field engineers who all interact with the system differently, often under time pressure and in locations with unreliable connectivity.

Work Order Creation and Scheduling

• Work order creation: create work orders from cases, from service accounts directly, and manually. Validate that incident types apply the correct service tasks and products to the work order automatically. Test the full lifecycle: creation, assignment, completion, and billing if D365 handles invoicing
• Schedule Board: the Schedule Board is the dispatcher's primary workspace. Have your dispatchers test it with a realistic set of bookings. Can they drag and drop to reschedule? Do resource skills and territory filters work correctly? Is the travel time calculation reasonable?
• Resource booking and availability: book a resource with a specific skill set and confirm that resources without that skill are filtered out. Test what happens when a resource is double-booked or unavailable due to leave. Test cancellation and rebooking workflows

Mobile App for Field Engineers

• Mobile app on real devices: the Field Service mobile app must be tested on the actual devices your engineers use, not emulators. Test on both iOS and Android if your team uses both. Test in areas with poor signal: offline mode must work, and sync must complete correctly when connectivity is restored
• Work order completion flow: the engineer should be able to complete a work order, record time and materials, capture a customer signature, and close the job entirely from the mobile app. Walk through this with actual engineers in a test environment. You will almost certainly find friction points that were not visible from the office
• Photo and inspection capture: if engineers are expected to capture photos of completed work or run inspection checklists, test that attachments upload correctly and that the checklist logic (required fields, conditional questions) works on mobile

Customer Asset Management

• Asset records: validate that customer assets are correctly linked to service accounts and that work order history against an asset is visible from the asset record. Engineers need to be able to see what work has been done previously on a piece of equipment before they arrive on site
• Preventive maintenance: if PM schedules are configured, test that work orders generate automatically at the correct intervals and that the scheduling respects resource availability and territory rules

5. D365-Specific UAT Challenges

Dynamics 365 presents a set of technical and organisational UAT challenges that are specific to the platform. These are the areas where projects run into trouble most often.

Security Roles and Teams

The Dynamics 365 security model is one of the most complex in the enterprise software market. It operates across multiple dimensions: business units, teams, record ownership, field security, and row-level security. A misconfigured security role will not throw a loud error. It will silently hide records, block actions, or prevent users from seeing data they need.

During UAT, every test persona needs to log in with their own credentials and their own assigned security role. Do not test with an admin account and then assume other users will have the same experience. Common issues that only surface during proper persona-based testing include: a sales rep who cannot see accounts owned by other team members even though the business expects shared account ownership; a service manager who cannot access the reporting dashboards because the dashboard was created under a different business unit; and a field engineer whose mobile app does not show all assigned work orders because of a territory restriction that was misconfigured.

Business Rules and Power Automate Flows

• Business rules: D365 business rules apply client-side or server-side validation logic to forms. Test that mandatory fields are enforced correctly, that field visibility rules trigger at the right point, and that calculated fields produce the correct values. Business rules interact with form scripting in ways that can produce unexpected behaviour under specific data conditions
• Power Automate flows: flows need to be tested under conditions that reflect real data volumes and edge cases. A flow that sends an approval email when an opportunity value exceeds £50,000 needs to be tested with a real email recipient, not a test mailbox that nobody checks. Test what happens when the approver does not respond: does the escalation path trigger? What happens if the flow errors mid-execution?
• Plugin and custom code testing: any server-side plugins or custom code needs to be tested with realistic data volumes. A plugin that runs on every account save might perform acceptably with 10 accounts in the test environment but cause timeouts when the full 50,000-account dataset is migrated

Data Migration: Accounts, Contacts, and Opportunity History

• Relationship validation: migrated accounts and contacts must retain their relationships. An account with 15 associated contacts in the legacy CRM should have 15 associated contacts in D365. Do not just validate record counts: navigate to specific accounts and verify the related contacts, cases, and opportunity history are present and correctly linked
• Ownership and assignment: migrated records must be assigned to the correct D365 user. This requires the legacy CRM user list to be mapped to D365 users before migration. Test that the assigned owner on a migrated opportunity matches the expected sales rep, and that the record appears in that rep's pipeline view
• Historical activities: if call logs, email history, and meeting records are being migrated from the legacy system, validate a sample of migrated activities against the source system. Activity migration is often deprioritised and rushed. If the sales team cannot see their historical interactions with key accounts, they will lose trust in the system immediately

6. How D365 CRM UAT Differs from ERP UAT

If you have read our guide to Business Central UAT, you will notice some structural similarities. Both require persona-based testing, both need proper sign-off, and both suffer from the same mistake: testing features instead of business processes. But the differences are significant enough to change your approach.

Shorter Cycles, Less Rigidity

CRM UAT cycles are typically shorter than ERP UAT cycles. Two to three weeks is normal for a D365 Sales-only implementation. This is partly because the blast radius of a CRM failure is smaller: a misconfigured pipeline stage will not corrupt financial data or prevent the business from invoicing customers. But shorter cycles also mean less time to catch things. You need to be more selective about what you test and more deliberate about getting the right users involved.

More Subjectivity, More Negotiation

ERP UAT is largely objective. Either the purchase invoice posts to the correct GL account or it does not. CRM UAT requires business judgement. The pipeline stages might be technically correct but still not match how the sales team thinks about deals. The dashboard might work perfectly but show metrics the sales manager does not find useful. You need a tester who understands the sales process, not just someone who can click through a script.

Expect more iteration in CRM UAT. When a sales rep raises feedback that a view does not show the right fields, that is not a bug. It is a requirements gap that needs to be assessed: is this a quick configuration change, a deferred enhancement, or a misunderstanding of what was agreed? Having that conversation during UAT, with proper documentation, is far preferable to having it two weeks after go-live when half the team has already stopped logging activities.

Sales Team Resistance

Sales teams resist CRM implementations more than any other user group resists ERP implementations. Finance has to use Business Central to do their job. A sales rep who dislikes D365 can run their pipeline in a spreadsheet and send updates via email. This makes their participation in UAT genuinely optional from their perspective, even if it is not from yours.

Address this directly. Frame UAT as an opportunity to shape the system before go-live, not a compliance exercise. Let sales reps raise changes during UAT. Some of those changes will be in scope, some will not, but the process of being listened to builds the engagement you need for adoption. Consultants who run CRM UAT as a tick-box exercise are setting up an adoption failure.

7. Getting Sign-Off from Sales Leadership

The hardest sign-off in any CRM project is not the technical sign-off. It is getting the Sales Director or VP of Sales to formally approve that the system is ready for go-live. This person is under no obligation to make your project timeline easier, and they have legitimate authority to delay go-live if they are not satisfied. Here is how to make that conversation productive.

Start by involving sales leadership in defining the UAT criteria, not just reviewing the results. If the Sales Director agreed at the start of UAT that pipeline reporting would be deemed acceptable if it shows current quarter pipeline by stage with drill-down to individual deals, you have a clear pass criterion. If you go into sign-off without agreed criteria, you will find that the goalposts move.

Produce a sign-off summary that sales leadership can understand without reading 200 test cases. Show them: how many tests were run, how many passed, how many outstanding issues exist, which of those issues are blocking go-live and which are accepted deferrals. A one-page summary with a clear go/no-go recommendation is more persuasive than a spreadsheet full of test case IDs. See our guide to the UAT sign-off process for more detail on structuring this conversation.

Be clear about what "accepted deferral" means. If the sales team has raised 12 change requests during UAT and 10 of them are being deferred to phase 2, that needs to be acknowledged in the sign-off document, along with the timeline for delivering those deferrals. Promises made verbally at a sign-off meeting are forgotten within days. Document them.

How LogicHive Helps

Managing Dynamics 365 CRM UAT in spreadsheets creates exactly the problems described above: no single source of truth, no real-time progress visibility, and a sign-off process based on email threads. LogicHive gives implementation teams a purpose-built UAT platform that covers the full cycle from test case creation through to sign-off.

Key capabilities for D365 CRM projects: structured test suites organised by module and persona, real-time readiness dashboards your project sponsor can view without asking for a status update, and a formal sign-off workflow that produces an audit trail. No per-seat fees for client testers, which matters when you are asking 20 sales reps to participate and you do not want the cost to spiral. From £72.99/month. See the full LogicHive feature set.