Building an External Scheduling Engine for D365 Project Operations | Generate msdyn_plannedwork Contours

How to Generate msdyn_plannedwork Contours in Dynamics 365 Project Operations (External Scheduling)

In Dynamics 365 Project Operations external scheduling, the platform can store and display time-phased hours — but the planned work contour (the day-by-day distribution) must be produced correctly so grids, estimates, and reporting behave as expected.

This post breaks down the first principles behind work templates → contours → msdyn_plannedwork, then gives a clear algorithm (plus validation steps) to generate the JSON stored on the Resource Assignment.

1) What problem are we solving?

Project planning needs a time-phased view of hours (day-by-day). In Project Operations, that view comes from the planned work contour stored on the Resource Assignment.

In external scheduling, you should assume that planned work must be calculated explicitly and stored as msdyn_plannedwork. If this field is empty or malformed, time-phased grids and totals won’t reflect the plan correctly.

2) What is a contour (first principles)?

A schedule isn’t “40 hours sometime next week.” A schedule is a distribution of work across working time. That distribution is a contour — the breakdown of hours by working day (or working interval).

In Project Operations, the contour is stored as JSON in:

msdyn_resourceassignment.msdyn_plannedwork

3) Work templates: the source of working time

Contour generation needs one consistent definition of “working time.” That definition comes from a work template (working days, daily windows, breaks, shift patterns).

Important: A work template can be applied at project or project task level. Enabling task-level templates typically requires customization (so the template can be chosen and stored per task). The contour algorithm stays the same — it simply uses the applicable template.

4) The contour algorithm

This approach produces a deterministic contour that:

• allocates effort only on working days defined by the work template
• skips non-working days entirely (no JSON entries)
• does not attempt leveling/overbooking checks (that’s a separate layer)

Inputs

• Assignment start and finish (from the task)
• Total effort for the assignment (hours)
• Working time per day from the work template

Steps

1. Find all working days between start and finish (inclusive) using the work template.
2. For each working day d, compute WorkingTime_d (hours).
3. Compute a single scaling factor Units so:
   Σ(Units × WorkingTime_d) = TotalEffort
4. For each working day:
   Hours_d = Units × WorkingTime_d
5. Build the msdyn_plannedwork JSON array:
   one entry per working day (or per working interval if your template has multiple intervals per day).
6. Save the JSON string onto the Resource Assignment.

5) Worked example (40 hours across 6 working days)

Scenario:

Total productive capacity across the window:

6 × 9.5 = 57.0 hours

Units:

Units = 40 / 57 = 0.7017543859

Hours per working day:

Hours_d = 0.7017543859 × 9.5 = 6.6666666667 ≈ 6.67

Result: the contour distributes planned work as 6.67 hours per working day for the 6 days in the template window.

6) Building the msdyn_plannedwork JSON

The stored value is a JSON array. Each entry represents the work allocation for a working day (or working interval). Each entry contains:

• Start (UTC timestamp in “/Date(…)/” milliseconds format)
• End (UTC timestamp in “/Date(…)/” milliseconds format)
• Hours (decimal hours for that day/interval)

[
  { "Start": "/Date(START_UTC_MS)/", "End": "/Date(END_UTC_MS)/", "Hours": 6.67 },
  { "Start": "/Date(START_UTC_MS)/", "End": "/Date(END_UTC_MS)/", "Hours": 6.67 },
  { "Start": "/Date(START_UTC_MS)/", "End": "/Date(END_UTC_MS)/", "Hours": 6.67 },
  { "Start": "/Date(START_UTC_MS)/", "End": "/Date(END_UTC_MS)/", "Hours": 6.67 },
  { "Start": "/Date(START_UTC_MS)/", "End": "/Date(END_UTC_MS)/", "Hours": 6.67 },
  { "Start": "/Date(START_UTC_MS)/", "End": "/Date(END_UTC_MS)/", "Hours": 6.67 }
]

7) What do “Start” and “End” mean?

For each working day, use the daily window defined by the work template:

• Start = the first working minute of the day (template)
• End = the last working minute of the day (template)

This keeps the contour aligned to the template — including breaks and non-working intervals.

8) Validation checklist (quick, reliable, repeatable)

1. Create a view for Resource Assignments that includes: Project, Task, Start, Finish, Total Effort (Hours), Planned Work (msdyn_plannedwork).
2. Validate the raw JSON:
   • Σ(Hours) = Total Effort
   • No entries on non-working days
   • Start/End align with the template day windows
3. Validate the UI distribution:
   • Open the project → Resource Assignments tab
   • Set the time scale to Day
   • Confirm daily hours match your contour (e.g., 6.67 across expected days)

9) Common pitfalls (and how to avoid them)

• Allocating on non-working days: skip those days entirely — no JSON entries.
• Using inconsistent working time definitions: always anchor contour generation to the chosen work template.
• Rounding drift: define a deterministic rounding rule (e.g., round to 2 decimals and distribute remainder on the last working day).
• Time zone confusion: validate using stored UTC values to avoid UI display surprises.

FAQ (for people searching)

Next in the series: we’ll build the working time engine behind this calculation — calendars, breaks, exceptions, and how to reliably compute “first working minute” and “last working minute” for a work template.