We actually read these.
Ideas submitted here go to the product team, not into a void. Add yours, vote on others, and comment on what matters to your business.
Talk to our Product Managers live: every other Monday, 1:00–2:00 PM ET → https://www.d-tools.com/cloud-product-office-hours
When a change order is approved, its products and labor become part of the project. What does not happen is any connection to the work plan the field crew actually follows. The approved items appear in the project item list tagged with the change order they came from, and that is where it stops.
Someone in the office then rebuilds the work by hand: create the tasks, retype the scope, attach the items one at a time, and estimate the hours again even though the change order already carries them. Notes written during the change order do not travel. Nothing on the resulting task says which approved change it came from.
The consequences are ordinary and repeated. Approved work gets scheduled late or missed entirely because it never entered the plan. The crew arrives without knowing what changed. Remaining hours on the schedule understate the real work because approved labor was never added.
Notifying other departments that a change order was approved, which is a separate request. Generating a starting schedule from a template, which builds the initial plan rather than amending a live one.
Change orders are routine on active projects, not exceptional. This gap sits exactly between office approval and field execution, and it is currently bridged by a person remembering to do it.