The retirement of Microsoft’s MB-240 certification exam on June 30, 2026 did not retire the work that Dynamics 365 Field Service consultants perform. Organizations still need reliable scheduling, complete asset histories, practical technician experiences and an accurate account of what happened during a service visit. What changed is the credential route: an older exam outline can help identify historical topics, but it is not a current booking destination or an assurance that a consultant can support a particular company’s deployment.
A readiness review should therefore test whether someone can work through operational exceptions without relying on the vendor demonstration script. This article is not a feature-by-feature configuration guide or a career guide. It is a practical assessment of consulting competence: the evidence a candidate or project team should produce before being trusted to configure, evaluate or support a live service operation.
Begin with the service promise and map who owns it
Choose a realistic business commitment. A customer reports a faulty refrigeration unit at a branch site, and the service provider promises a qualified technician within a defined response window. Ask who accepts the request, which agreement governs it, who may reclassify the priority and what information is required before dispatch. The system should make those decisions explicit rather than relying on a senior scheduler’s memory.
Build a simple lifecycle diagram covering intake, asset identification, work order creation, incident type, resource requirement, booking, technician execution, inventory consumption, customer sign-off and billing. At each transition, name the owner and the data needed. You are assessing whether a consultant understands the purpose of these controls, not whether they can repeat a sequence of clicks.
Set measurable acceptance criteria. A work order should not become ‘completed’ if a mandatory safety check or resolution note is missing. A customer should not be invoiced twice because an offline mobile device replayed a submission. A dispatcher should be able to identify which appointment moved when a technician became unavailable. If the acceptance criteria are vague, a visually attractive configuration can conceal a broken operating process.
Examine work-order and asset data quality before the schedule
Field Service implementations inherit imperfect source data. One physical asset may appear under two names, contracts may have conflicting coverage dates, and older tickets may not identify the installed equipment. A consultant should know when to resolve those records before migration and when to preserve their history with an explicit caveat. Otherwise technicians may travel to the right customer and service the wrong device.
Test a case with two similar assets at one site. Which identifier distinguishes them? How is warranty status calculated? What prevents an employee from attaching a recurring fault to the wrong serial number? What happens when the asset is replaced but the location remains the same? These questions require data ownership and validation rules, not an extra custom field for every exception.
Have the trainee design a minimal quality report: assets without location, work orders without the required classification, duplicate serial numbers and visits missing completion evidence. The exact report implementation can differ by organization. What matters is whether those records are visible to an accountable data owner and whether there is a way to fix them without rewriting history.
Put scheduling under an intentional constraint
A successful initial booking proves very little. Introduce one unavailable technician, a new urgent call, a skills requirement, a part that has not arrived and a travel-time conflict. Ask the candidate to explain why a particular resource was selected and what business rule they would refuse to override. Availability, territory, capability and customer promises are not interchangeable constraints.
The correct decision may be to defer the appointment or negotiate a changed service window. Resource Scheduling Optimization and the schedule board can support choices, but they do not relieve managers of approving policies. A consultant should be able to explain the difference between a displayed suggestion, a dispatcher’s decision and a customer-facing commitment. Preserve a record of the rationale when changing an existing booking.
Review a disrupted day rather than a perfect schedule. Which work orders need reassignment? Does an agreement guarantee a particular response window? Can a technician with the right skills service two affected customers without violating travel or shift rules? The trainee should produce a short changed-bookings report and escalation note, not only a screenshot of a green calendar.
Prove the mobile process survives loss of connectivity
A technician’s device may go offline in a basement or an area with poor coverage. Give the trainee a service visit that requires photos, a parts issue, a checklist and a customer signature. Let the technician record meaningful work while offline in a supported configuration, then introduce a conflicting update before the device reconnects. The readiness question is what the user sees and which record wins—not whether the offline checkbox was selected in settings.
Test whether the mobile screen shows the correct equipment history and whether the technician can safely find the next step without hunting through an unfamiliar data model. Performance matters when staff are wearing gloves, dealing with poor lighting or operating under time pressure. If mobile data is delayed, the interface should not invite a dangerous assumption about inventory or approval status.
A strong candidate can describe synchronization scope, conflict handling, record security and troubleshooting evidence appropriate to the deployed mobile app. They should not promise that every table, attachment or custom component automatically supports offline mode. Product-version and application limitations must be checked in the organization’s sanctioned test environment.
Reconcile parts, labor and customer billing
A work order can be technically complete while its accounting story is wrong. Build a test where a technician uses two parts, returns one unused part and spends longer on site than estimated. Verify the source of inventory quantities, the warehouse or van stock location, the labor entries and the applicable contract charges. Explain who has authority to correct a posted quantity and how that correction propagates.
In the readiness record, place the signed service outcome alongside inventory movement and invoice inputs. The numbers should tell one consistent story. If the customer has an agreement that covers labor but not a replacement component, the calculation should be understandable to customer service and finance. Do not assume a standard price list captures every agreement or tax requirement without configuration.
Ask the trainee to diagnose a discrepancy: a part appears on the mobile form but not on the expected inventory balance. Did the transaction synchronize, reach the intended warehouse, trigger a reservation or remain unposted? This is a better test of practical competence than memorizing all the screens that could contain a part number.
Judge automation and customizations by recoverability
Automation can route work orders, warn about overdue commitments and remind technicians of missing evidence. Before enabling a flow, require the consultant to name its trigger, permission context, failure behavior and owner. What happens if two events arrive close together? Is an action idempotent? Can a failed integration be replayed without creating duplicate work orders or sending the customer multiple notifications?
Custom fields and forms should have a documented business purpose. A quick customization that hides the system’s intended workflow may create long-term maintenance debt. Ask the candidate how they would test a change in a separate environment, plan deployment, communicate to users and roll back if adoption or data quality worsens. A consultant who can say ‘we should use supported configuration here’ is demonstrating judgment, not a lack of technical ambition.
Integration decisions need the same discipline. Identify which application owns the customer, asset and billing records; avoid vague statements that data automatically stays consistent because two Microsoft products are connected. Consider error queues, data loss, permissions and recovery when a connection fails partway through an update.
Use a scorecard based on evidence, not an obsolete exam label
A practical readiness scorecard should cover service-process explanation, asset data, scheduling trade-offs, mobile exception handling, inventory and billing reconciliation, testing and change management. For each, record the scenario, the candidate’s decision, supporting evidence, unresolved risk and next action. A pass cannot be based solely on self-reported confidence or attendance at training. Have a second reviewer challenge at least one failed scenario and ask the candidate to defend the recovery decision.
Document the limits of the review. A small sandbox cannot prove production-scale performance, and a candidate who can repair one standard work order may not yet be competent to design a multi-region rollout. Record which conditions were simulated and which depend on further controlled tests. This is how a readiness review remains useful instead of becoming an informal credential with no criteria.
The old MB-240 objectives can still be read as a historical outline of service skills, but Microsoft’s retirement notice means they must not be marketed as an exam candidates can newly book. For active credentials, consult Microsoft’s current catalogue. More importantly, a trustworthy Field Service consultant can take a complex service day, surface the key risks, configure and test the controls, and explain the result to dispatch, technicians, service leadership and finance. That evidence is more durable than a retired exam code.