Dynamics 365 Project Operations in practice: a seven-part series on building an external scheduling engine, plus field notes from large turnarounds.
8 articles
Why integration-created work orders silently never schedule, what a due date and a duration have to become before anything can be placed, seeding tasks that arrive with no dates, and who owns the dates afterwards.
Why a synchronous plugin cascade deadlocks and times out on a real program, the two changes that remove it, and the orchestrator, pending-change table, Azure Function and Gantt API pattern we ended up with.
Forward and backward passes over the task graph in working time, what the due date anchors and why exactly one task must be the end, float that is allowed to go negative, and the honest options when a constraint contradicts a dependency.
Where working time actually lives in Project Operations, how to expand a calendar into something you can compute against, the three functions every other part of the engine calls, and the horizon and fallback mistakes that only show up at scale.
Thousands of tasks, a fixed end date and mostly contractors. How a turnaround maps onto Project Operations and Field Service, and exactly where the standard scheduling engine runs out.
The planning tables behind an externally scheduled Project Operations program, how tasks, dependencies and assignments relate, and the order to create them in.
Status-date scheduling: pushing unearned work past today with tool-agnostic rules, so a stable plan keeps telling the truth as the program moves.
How planned work contours spread a task's effort across the days it runs: the template, valid working days only, and the JSON the platform stores.
We design and ship the systems behind these posts. Tell us what you are wrestling with and we will bring the clarity and the structure.
Book a meeting
