Almanac
Microsoft/d365fsDynamics 365

Consultant-focused KB for Microsoft Dynamics 365 Field Service: implementation notes, gotchas, and configuration decisions beyond the official docs — across work orders, scheduling and dispatch, resource management, mobile app, asset management, inspections, IoT, Copilot, and administration.

feature-copilot-work-order-summary.mdv1 · history
CurrentApplies to Field ServiceUpdated 6 days agoSource Microsoft Learn

What it does

Generates an on-demand, natural-language recap of a work order or a bookable resource booking, pulling in bookings, activities, notes, products, services, service tasks, asset details and the asset's work order history. It's the feature everyone still calls "work order recap" — the docs and the URLs use both names. It's generally available, not preview.

Key facts

  • Requires a paid Field Service environment. It does not work in trial environments, which catches out anyone building a demo on a trial tenant.
  • Turned on by the administrator through Copilot for work order in the Field Service default settings. It is disabled by default in United Kingdom environments — relevant for most of the clients reading this.
  • Two separate configurations exist: one for the Work Order table and one for Bookable Resource Booking. Enabling or customising one does nothing to the other.
  • The default summary is status-aware. Unscheduled work orders get requirement and scheduling context, Scheduled and In Progress get asset detail and asset history, Completed/Posted/Cancelled get cost, pricing and invoice detail.
  • Summary configuration lives at Settings > Copilot settings > Summary Configuration. Turn on Configure summary, then add or remove table/column pairs and test against a real record in the Sample summary panel.
  • Turning on Configure summary removes the built-in status-based optimisation. You get the fields you chose, in every status, and nothing else. There is no way to keep the default behaviour and add one extra column.
  • The summary is never saved. It is generated per user, per request, and is visible only to the person who pressed Generate. Nothing lands on the record, so there is nothing to report on or audit.
  • Summaries respect the caller's security roles and personalisation settings — language, timezone, date format. Users also need read access to the msdyn_fieldservicesummaryconfiguration table or configured summaries won't render.
  • Microsoft has tested the feature in English only. Other languages will produce output, but quality is not guaranteed.
  • Feedback (the like/dislike buttons) is on by default and is controlled per environment on the organisation table. The tenant-wide Copilot feedback switch in the Power Platform admin centre does not govern it.

When to use / skip

Turn it on. It is one of the few Copilot features in Field Service that costs nothing extra, needs no separate agent licence, and produces something a dispatcher will actually read. The dispatcher use case — "what's the history on this account before I ring them back" — is where it earns its keep.

Where I'd be more careful is the custom summary configuration. Clients see the config screen in a demo and immediately want twenty custom columns in the summary. That trade is worse than it looks: you lose the status-aware default behaviour permanently for as long as the toggle is on, and you cannot tune the prompt itself, only the data fed into it. Unless the client has genuinely important data in custom tables that the default ignores, leave Configure summary off.

Skip it entirely if the client is on a trial environment, if their region isn't covered by the Copilot availability report, or if their work order data is thin. A summary of empty fields is just a slower way of reading an empty form, and it will damage confidence in every other AI feature you're trying to sell.

Configuration decisions

  • Whether to enable summaries on Work Order, Bookable Resource Booking, or both — dispatchers usually want the work order, technicians the booking.
  • Whether to accept the default summary or turn on Configure summary, accepting the loss of status-aware optimisation in exchange for custom columns.
  • Which custom tables and columns are worth including, and whether any of them are populated reliably enough to summarise.
  • Whether to leave feedback collection on. Regulated clients frequently want it off, and that is an organisation-table setting, not a tenant one.
  • Where the summary control appears: the out-of-box forms already carry it, but adding Field Service Copilot - Recap to custom forms means binding it to the System Status choice column and hiding the label.
  • How configurations move between environments — they are data, not solution components, so plan for the Configuration Migration tool.

Gotchas

  • Configurations do not travel in your solution. If you skip the Configuration Migration step, UAT has custom summaries and production quietly falls back to the default with nobody noticing.
  • If Field Service was preinstalled in the environment, the summary configuration records may be missing altogether. You'll need Create default configurations before the settings screen behaves.
  • UK environments start with the feature off. Consultants who tested on a US sandbox and assumed parity get an awkward moment on the client's tenant.
  • The summary is not stored, so "can we show the recap on the printed work order" or "can we report on summaries" is a no. If the client wants persistence, that is a custom flow calling the model directly, not this feature.
  • Cross-region tenants need data movement enabled. Without it, the control renders and then does nothing useful, with no obvious error pointing at the cause.
  • Poor data in, poor summary out. Field Service implementations with free-text-only notes and empty service tasks produce recaps that read like padding, and users abandon the button after a fortnight.

Consultant notes

  • Demo it on a real, messy work order with genuine history — an asset with three prior visits. Demoing on a clean seeded record makes the feature look pointless.
  • Set the expectation early that the summary is a reading aid, not a record. Someone will ask whether the technician can be held to it.
  • Push back hard on custom summary configuration in the first release. Ship the default, gather feedback for a couple of sprints, then configure if there's a real gap.
  • Before go-live, check the Copilot availability report for the client's region and language, and confirm the environment is paid rather than a converted trial.
  • Agree with the client whether feedback telemetry stays on. It's a two-minute conversation now and a governance escalation later.

Worth another look if Microsoft ever lets you keep the status-aware default while adding custom columns, or if summaries become persistable.

Was this accurate?