MB-240 common mistakes
MB-240 · Understand the traps and how to avoid them.
Creates a Bookable Resource for a technician but leaves Enable for Scheduling off, the Organizational Unit blank, or Start/End Location unset, then expects the person to show up in Schedule Assistant results.
It is natural to assume the User record alone makes someone schedulable. Scheduling actually runs off the Bookable Resource record and its constraints: resource type, organizational unit, location and capacity. A blank organizational unit drops the resource out of territory and requirement filters, and a missing location fails the onsite check.
What to do instead
Build the Bookable Resource from the user, set Resource Type to User, turn on Enable for Scheduling, set Start/End Location (or inherit from the resource), assign the correct Organizational Unit, then prove it with a test requirement in Schedule Assistant before configuring anything else.
Gives every technician the Field Service - Administrator role, or assigns Field Service - Resource but never shares the Field Service mobile app module, then investigates 'missing data offline' as a sync defect.
Security roles and app access look like one setting in the UI, and admin is the easiest role to hand out during a pilot. The mobile app is a separate first-party app: a user needs both the app and the right role, and blanket admin rights hide the real table and column gaps that only appear for a least-privilege user.
What to do instead
Assign least-privilege roles (Field Service - Resource for technicians, Field Service - Dispatcher for schedulers), share the correct app module with those users or teams, and retest with a pilot account that has only those roles so permission gaps surface before go-live.
Closes a work order while one or more of its bookings are still open, or flips the work order back to an earlier system status to 'unstick' a job.
Work order status is driven by booking status roll-up, but candidates treat Work Order System Status as a free-form picklist they can move in any direction. Reopening and re-closing changes posted and substatus values, re-fires business logic, and leaves open bookings attached to a closed record.
What to do instead
Complete or cancel every booking first so booking statuses roll up, then move the work order through Open - Unscheduled, Open - Scheduled, Open - In Progress to Closed - Posted, and record the real outcome in the substatus instead of reopening the record.
Adds an incident type to an already-created work order and assumes the service tasks, products and services came with it, or records spare parts on a service task instead of as incident type products with quantities.
Incident types behave as templates: items are copied at the moment the incident type is applied, and that copy step is easy to overlook when the type is added later. Only incident type products carry the quantity and unit data that later drive inventory consumption and invoicing.
What to do instead
Apply the incident type at creation (or accept the copy prompt when adding it afterwards), then verify work order service tasks, products and services were generated. Put parts with quantities on the incident type's products and labour on its services.
Creates a custom booking status for travel or reporting and only sets the display name, then expects technicians to see a distinct state or the work order to move forward.
A Booking Status row carries both a name and a system Status value, and only a small set of Status values exist (Scheduled, In Progress, Completed, Canceled). Candidates assume the name drives behaviour, so the new status behaves exactly like Scheduled and nothing on the work order changes.
What to do instead
For every custom booking status, set the system Status value it should represent and confirm how it rolls up to the work order status. Remember the mobile app's Complete action is bound to the booking status configured as Completed.
Drags every job onto the schedule board manually and never opens the requirement's fulfillment details, so onsite jobs get offered to resources with no matching location and Schedule Assistant returns nothing.
The assistant applies hard constraints: work location (onsite versus location agnostic), duration, time-from and time-to promise, resource type, territory and characteristics. Candidates test with a location-agnostic requirement, then are surprised when a real onsite requirement matches no one.
What to do instead
Before scheduling, open the requirement and confirm Work Location, Duration, Time From/To Promise and required characteristics. Use Schedule Assistant to see which constraint removes each candidate, and fall back to manual board moves only after the requirement is correct.
Deploys the mobile app with the default or an all-tables offline profile, or adds a table to the app without adding it to the offline profile, then blames the app for sync errors and records that never appear.
The mobile app reads the local offline store first, not live Dataverse. Anything absent from the offline profile is simply not on the device, and an unfiltered profile downloads enormous volumes that slow or break sync on a technician's connection.
What to do instead
Create a purpose-built offline profile with only the tables and columns technicians need, add relationship filters (bookings for the current user, work orders within the next few days), and validate by completing a full sync and working in airplane mode before rollout.
Records a warehouse count correction as an inventory transfer, or receives a purchase order and expects on-hand product inventory to change without posting the receipt.
Adjustment, transfer and receipt all look like 'moving stock' in the UI, but only an adjustment changes quantity in place, a transfer moves stock between warehouses, and on-hand inventory updates only when the receipt is posted. The three screens are easily confused under exam time pressure.
What to do instead
Use Inventory Adjustment for count corrections inside one warehouse, Inventory Transfer to move stock between warehouses, and a posted Purchase Order Receipt to bring stock in. Then check the Product Inventory record for the specific warehouse to confirm the resulting quantity.
Adds purchase order lines as free text or with a mismatched unit of measure, and never confirms the vendor and currency, then cannot reconcile received quantities against inventory.
Purchase order products must reference a real Product record with a unit of measure, and the PO must be tied to a vendor for pricing and receipt. A free-text line or unit mismatch breaks the receive step and leaves the order stuck partway through its system statuses.
What to do instead
Create purchase orders with a Vendor and Currency, add purchase order products that reference existing Product records with matching units of measure, and walk the order through Draft and its submitted and approved statuses to Received before posting the receipt.
Builds booking reminders, agreement generation or work order creation as cloud flows authored outside the solution with hard-coded environment connections, then finds the flow broken after deployment to test or production.
Power Automate is the obvious automation tool, so candidates reach for it first and build in the default environment. Flows outside a solution carry no connection references and are not transportable, and a data loss prevention policy in the target environment can block the connector entirely.
What to do instead
Author flows inside the solution using connection references, use the Dataverse connector for Field Service tables, confirm the target environment's DLP policy allows those connectors, and prefer built-in capabilities such as booking reminders and agreement generation where they already exist.