Almanac
Microsoft/d365fsDynamics 365

Consultant-focused KB for Microsoft Dynamics 365 Field Service: implementation notes, gotchas, and configuration decisions beyond the official docs — across work orders, scheduling and dispatch, resource management, mobile app, asset management, inspections, IoT, Copilot, and administration.

d365fs/02-scheduling-and-dispatch/feature-schedule-board-configuration.md
feature-schedule-board-configuration.mdv1 · history
CurrentApplies to Resource SchedulingUpdated 6 days agoSource Microsoft Learn ↗

What it does

The schedule board is the dispatcher's Gantt, list and map view of resources and their bookings. Almost everything a dispatcher sees on it — which resources appear, which columns, which tooltips, which requirement panels sit at the bottom — is driven by saved configuration on a schedule board tab, not by the code.

Key facts

  • Configuration lives on the Schedule Board Setting table (msdyn_scheduleboardsetting). One record per tab, and the tab named None holds the defaults inherited by everything else.
  • Settings split into two places that people confuse: Board view settings (time zone, working time, working days, time resolution, row height, show canceled, show travel duration, show booked percentage) and Scheduler settings / board settings (sharing, map views, schedule assistant behaviour, page counts, templates).
  • Sharing is Everyone, Specific people, or Just me. Specific-people sharing uses ordinary record sharing (Read/Write/Append/Share) via Manage access. Granting board access through custom security roles and team permission editing is explicitly not supported.
  • Time scales are hourly, daily, weekly and monthly. Several features are hourly-only: booking tooltips, custom booking templates, booking rules, travel duration display and resource map tooltips. Daily/weekly/monthly are aggregate views.
  • Weekly view always starts on Sunday. There is no setting for this.
  • Requirement page count and Resource page count cap how many records load per page in the lower pane and resource list. These are the first knobs to touch when a board is slow.
  • Retrieve resources query is raw FetchXML controlling how the resource list is fetched, filtered and sorted. Resource cell template and Custom booking template are HTML/CSS snippets controlling what renders inside a resource row and a booking block.
  • Per-entity settings ("schedule types") let you give work orders, cases and custom schedulable entities different booking tooltip, requirement details and schedule assistant requirement views.
  • Disable default extensions stops a board inheriting the default client-side extensions, including the RSO extension tab controls.
  • The board caches per-user state in the browser: last tab, map panel open/closed, Gantt vs list, view mode, column widths, requirement panel filters, and the board start date for 15 minutes.

When to use / skip

Every Field Service project configures the board — the question is how far. A first pass that sets time zone, working days, a sensible resource retrieval query and two or three requirement panels covers most deployments. Deep customisation — custom booking templates, cell templates, custom web resources in the actions area — is worth it only where dispatchers genuinely make decisions off information the default cells don't carry (SLA state, parts on hand, escalation flags). If the client's dispatch team is three people covering one territory, don't build twelve tabs; build one and spend the time on filters instead. The one thing worth doing properly on day one is the tab-per-territory or tab-per-work-type split, because dispatchers organise their day around it and retro-fitting it means re-teaching them.

Configuration decisions

  • Tab strategy: one board per territory, per work type, per shift, or a single board driven by filters. This drives the retrieve-resources query and territory filter behaviour.
  • Whether Apply territory filter to requirements is on, so the bottom pane follows the resource territory filter rather than showing the whole backlog.
  • Which requirement panels appear at the bottom, in what order, and whether the default panels stay visible at all.
  • Schedule assistant scope on this board: All resources versus Resources visible on board, plus whether unavailable resources are hidden or dimmed.
  • Whether bookings are visualised from Start of travel or Estimated arrival — this changes what dispatchers think a booking's start time means.
  • Sharing model per tab, and whether you accept that tabs shared to "Everyone" will be edited by whoever opens them.

Gotchas

  • Board settings are data, not solution components by default. Moving tabs between environments means moving msdyn_scheduleboardsetting records — plan for a data migration or configuration migration step, or accept that someone rebuilds them in production.
  • Editing the None tab changes defaults for every board that hasn't overridden the setting. It is the fastest way to make a global mess.
  • Booking rules and custom booking templates silently do nothing in daily, weekly and monthly views. Users report "the validation doesn't work" and they're right — for the view they're in.
  • A hand-written Retrieve resources query that doesn't account for inactive resources or resource type will quietly show ex-employees for months.
  • Switching between the classic and current board resets requirement filters and column widths, because the state is browser-cached per board. Users read this as data loss.
  • The requirement view uses "starts with" matching on the search box for performance. Dispatchers typing a fragment of a customer name find nothing and assume the record is missing; column-level filters give "contains".

Consultant notes

  • Demo the board with the client's own territories and a realistic booking density. An empty board demos beautifully and tells them nothing about whether row height and time resolution work at 40 technicians.
  • Agree early who owns board configuration after go-live. If it's the dispatch lead, restrict it to a named few — shared boards get edited by accident.
  • Before go-live, load-test the board at peak: real resource counts, real backlog, real number of open tabs. Then tune page counts and the resource query rather than blaming the network.
  • Push back on requests to put everything in the booking cell. Two or three fields plus colour is readable at a glance; six is not.
  • Check time zone settings against resource work hours before UAT. Nearly every "work hours are wrong" ticket in the first fortnight is a board time zone mismatch.

Worth another look when the board UI changes in a release wave, or the first time a dispatcher says the board is slow.

Was this accurate?
Related
Schedule assistant and its filters02-scheduling-and-dispatchResource Scheduling Optimization deployment and configuration02-scheduling-and-dispatchBookable resources and resource types03-resource-managementChoosing Resource Scheduling Optimization or manual dispatch11-decision-guidesResource work hours, calendars and work hour templates03-resource-managementRSO goals, scopes and optimisation schedules02-scheduling-and-dispatch