What it does

Every bookable resource has a calendar of working hours, breaks, time off and non-working time. That calendar is what the schedule board shades and what the schedule assistant searches. Work hour templates let you define a pattern once and push it onto a set of resources instead of editing each calendar by hand.

Key facts

• Work hours live on the Work Hours tab of the bookable resource. Underneath they are Dataverse calendar and calendar rule records, the same structures used for service scheduling — they are not a Field Service-specific table.
• Work hour templates are created under Resources > Work Hours Templates. You can seed a template from an existing resource's hours.
• Applying a template is capped at 25 resources at a time, and that is a stated performance limit rather than a soft suggestion. Bulk onboarding means batching.
• Capacity on a working hour block defaults to 1 and controls how many simultaneous bookings the resource can take. Setting it to 0 makes the resource unavailable for that period without deleting the hours.
• Breaks are added from the ellipsis on a working hour block and have a 30 minute minimum.
• Time off is entered as its own entry and greys the slot on the board while removing the resource from schedule assistant results for that window.
• Business closure is separate from time off. A calendar observes organisational closures only when the underlying rule has the closure flag set.
• Three supported APIs exist for calendar work: msdyn_SaveCalendar, msdyn_DeleteCalendar and msdyn_LoadCalendars. They cover bookableresource, msdyn_resourcerequirement, msdyn_workhourtemplate and msdyn_project.
• The APIs accept exactly one recurrence shape: FREQ=WEEKLY;INTERVAL=1;BYDAY=…. FREQ and INTERVAL cannot be varied; only the days in BYDAY can. No spaces in the string.
• The API route requires platform 9.2.21055 or above and Universal Resource Scheduling 3.12.45.7 or above, and there is a UseV2 flag that changes how overlapping rules resolve. Under V2, daily occurrences and time off rank above weekly recurrences; among equal-rank rules the most recently modified wins.

When to use / skip

Templates are worth setting up on any project with more than a handful of resources on a shared pattern — which is nearly all of them. Skip them only where every engineer genuinely has a bespoke rota, and even then a template per shift pattern usually beats none.

The API is a different question. Reach for it when the client has an external WFM or rota system that owns shift patterns and Field Service is downstream, or when onboarding volume makes the 25-resource cap painful. Do not reach for it to write calendar rule records directly — the ranking, splicing and inner-calendar logic behind overlapping rules is not something you want to reimplement, and hand-written rules are the classic cause of calendars that render one way on the board and another way in the assistant. If the client's shifts change weekly and the source of truth is a spreadsheet, be honest that an integration is a project of its own, not a configuration task.

Configuration decisions

• Which shift patterns exist, and therefore how many templates you need. Resist one template per team; go by pattern.
• Whether capacity above 1 is used at all. It is the right answer for facilities and pools and usually the wrong answer for a mobile engineer.
• Whether breaks are modelled in the calendar or absorbed into job duration estimates. Modelling them is more honest and makes the board busier.
• Whether time off requires approval (the Time Off Approval Required flag on the resource) or is self-service from the mobile app.
• Whether organisational closures — bank holidays, shutdowns — are handled once centrally as business closure or repeated as time off per resource.
• Whether shift data is mastered in Field Service or in an external system, and if external, whether the sync is one-way and how often it runs.

Gotchas

• The calendar is stored in the resource's time zone. Change the time zone on the resource after the hours exist and the hours move. Set the time zone first.
• Applying a template to a resource that already has hours does not always give you a clean slate; check a sample resource's calendar afterwards rather than assuming.
• You cannot delete a single occurrence out of a recurrence through the API, and you cannot create, edit or delete all-day recurrences at all. Plan around it rather than discovering it mid-sprint.
• Breaks cannot be deleted on their own via the API — they go when the parent working hour goes.
• Time off supports occurrences but not recurrences through the API, so a repeating every-other-Friday arrangement has to be written as individual entries.
• Overlapping rules resolve by rank and recency, not by what looks most specific on screen. Two people editing the same week can produce a calendar neither of them intended.
• A resource with capacity 0 still appears on the board. Dispatchers read that as available and raise a ticket.

Consultant notes

• Get work hours in before anything else in a UAT environment. Almost every "the assistant returns nothing" defect traces back to an empty or mis-zoned calendar, and chasing it later wastes days.
• Demo time off and the resulting grey block on the board early. It is the fastest way to get scheduling managers to care about calendar hygiene.
• Tell the client plainly that the 25-resource template limit exists, so nobody plans a 400-engineer cutover as a single afternoon's admin task.
• If shift patterns come from an external system, agree ownership before build: who wins when the two disagree, and what happens to bookings that fall outside newly shortened hours.
• Before go-live, pick five resources across different time zones and shift patterns and eyeball their board rows against the client's rota. It catches more than any amount of config review.

---

Worth revisiting if the calendar APIs pick up recurrence support beyond weekly, or if the 25-resource template cap moves.