Dynamics 365 Field Service to Preserve Booking End Times for Late Technician Completions

What Microsoft's roadmap entry promises​

The AI at Work roadmap item, ID 573239, describes a new Field Service setting called Set End Time on booked resource completion. Microsoft lists it as In development, with preview projected for October 2026 and general availability for February 2027. It covers the Worldwide (Standard Multi-Tenant) cloud on Android, iOS, desktop and web. Those are projected dates, not a commitment. Microsoft's roadmap says its release estimates and descriptions can change. Nothing published so far shows the preview has started.

According to the roadmap description, the setting works like this:

• Yes (default): Nothing changes. When the booked resource completes a booking without supplying an End Time, Field Service sets End Time to the moment of completion and recalculates Duration.
• No: Field Service keeps the existing End Time and Duration when the booked resource completes the booking, unless the completion request explicitly supplies a different End Time.
• Completion by someone else or by an integration: End Time is preserved under either value.
• Effective timestamp: With the setting at No, the retained or supplied End Time becomes the effective Completed timestamp. Timestamp-derived booking journals and automatic time entries then line up with the recorded end of work.
• Audit trail: Dataverse audit fields still show when the completion was actually submitted, so the late paperwork stays on record.
• Scope: The setting applies only to future completions. It does not rewrite historical bookings.

In short: if you set the toggle to No, tapping "Completed" no longer moves the booking's end time, unless someone deliberately supplies a new one.

A six-year-old complaint finally gets its toggle​

This problem is old. Microsoft's Dynamics Ideas portal has a request titled "Toggle for 'Update End Time' (Y/N) on the Booking Status," with comments dating to 2020. One partner described the problem plainly: if a technician forgets to close the BRB as complete one day, then when he finally completes it, the BRB will update the end time to current time. Another commenter said Microsoft Support told us that right now there's still no plans to change this behavior and if we want to prevent it we have to write a customization that sets the End Time/Duration back to the original value after a "Completed" status change occurs.

Microsoft's first answer covered only part of the request. In the 2023 release wave 2 plan, the company shipped "Complete bookings while preserving end time." Early access began Jul 31, 2023, with general availability on Oct 2, 2023, and it was enabled for users automatically. Under that change, if a user updates a booking status to Completed on behalf of an assigned resource, the booking's end time will preserve the previous end time value.

That fixed the dispatcher-cleanup case but left the original one: the technician who completes their own booking late. Not everyone was satisfied. One commenter on the idea argued that Microsoft have misinterpreted the idea from the customer and are introducing more issues than they are solving. The toggle is the key and it was not introduced with the change. The new setting is the toggle that commenter was asking for. It sits at the organization level, not on each booking status as the original idea proposed.

In short: the 2023 fix covered completions made on a technician's behalf. The 2026 roadmap item covers technicians completing their own bookings, which is what the community originally asked for.

Why one timestamp matters so much​

You might ask why a single datetime field deserves a roadmap entry. In Field Service, the booking's end is an input to time, cost and reporting records.

Microsoft's current lifecycle documentation describes the default: when a technician sets a booking to Completed, the duration updates to the actual duration of the booking, and the end time updates to reflect the time the status changed to completed. Several processes then run off that event:

• Booking journals. When a bookable resource booking status changes to Completed, the system creates booking journals per the booking timestamps. Journals split time into travel, working hours, break, overtime and business closure. A late completion tap can turn real working time into phantom overtime.
• Time entries. You can use booking timestamps to automatically generate time entries. To enable that feature, set the Field Service setting Time Entry Generation Strategy to Auto Generate from Booking Timestamps.
• Actuals. When the Work Order System Status changes to Closed-Posted, the system creates records for actuals based on the time entries. These records represent the internal cost of the technician's time.
• Work order Completed On. Microsoft's lifecycle documentation says booking completion updates the work order's Completed On field with the booking's end time, and editing the booking end time updates that value.

Picture a technician whose shift ends at 3:00 PM. They finish at 2:15 and tap Completed at 6:40. Under the default behavior, the journals can show more than three hours of overtime that was really driving and dinner. That carries into labor cost, utilization dashboards and possibly an awkward payroll conversation. With the setting at No, the booking keeps its recorded end and the journals reflect the work that was actually done.

There is one scoping detail worth knowing. Microsoft notes that time entries are only automatically created for work order bookings and not for independent bookings or bookings related to other tables. The End Time behavior applies to booking completion generally. The time-entry benefit only reaches bookings that generate automatic time entries in the first place.

What the setting doesn't change​

The roadmap entry sets clear limits. The new setting does not change:

• The booking-status lifecycle. Completed still means Completed, and status-driven work order transitions still apply.
• Invoice generation. Invoicing stays tied to the work order. Per Microsoft's documentation, a back-office worker moves the work order to Posted, and if products and services were used, this status triggers Invoice generation, depending on the system's configuration in Field Service Settings.
• The Work Order Completed On calculation. The roadmap says this still uses the latest eligible booking End Time. With No selected, Completed On should reflect the preserved end rather than the moment someone tapped the button, because the calculation reads End Time. That is an inference from the described behavior, so confirm it in testing.

A practical playbook for admins​

Microsoft hasn't published a setup procedure beyond saying the setting lives in Field Service settings. The roadmap entry doesn't specify navigation paths, permissions, API field names or rollout controls, so don't assume any. The following checklist is based on the documented behavior, not official Microsoft guidance:

1. Find out whether you have this problem. Compare booking End Times with Dataverse audit timestamps for completions. If technicians routinely complete bookings long after leaving the site, the No setting is worth considering.
2. Map what reads End Time. Check your Time Entry Generation Strategy and Time Cost Actuals Source settings, plus any Power Automate flows, plugins, ERP integrations or Power BI reports that read booking End Time or Duration.
3. Decide who sets the real end time. With No selected, the completion action no longer records when work ended. Someone or something has to keep End Time accurate, whether that's the technician entering it, a supplied value in the completion request, or the scheduled end. If scheduled ends are routinely wrong, preserving them won't help.
4. Test both kinds of completion in a sandbox. Complete one booking as the booked resource and one as a dispatcher or integration. Then compare End Time, Duration, booking timestamps, journals, automatic time entries, work order Completed On and audit fields.
5. Test the override. Complete a booking with an explicitly supplied End Time under the No setting and confirm the value sticks.
6. Retire old workarounds carefully. If you built a plugin to restore End Time after completion, as the Ideas thread suggested, check whether it conflicts with the new setting before removing it.

The bottom line​

This is a small switch with real effects on payroll and costing. Microsoft has been tightening completion behavior gradually: first preserving End Time when someone completes a booking on a technician's behalf, and now proposing an opt-in toggle for technicians completing their own bookings late. The default stays the same, so nobody's journals change overnight. The new behavior applies only going forward, and the audit trail keeps the record of when completion was submitted.

The obvious risk is that switching to No only works if End Time was right to begin with. If your technicians' schedules are fiction, keeping them will produce cleaner-looking records that are still wrong. Still, organizations that have spent years writing plugins to undo late End Time updates should find this a welcome change, assuming the projected October 2026 preview and February 2027 GA hold.