Work Centers, Machine Centers, and Shop Calendars in BC
Before Microsoft Dynamics 365 Business Central can schedule a single operation, it needs a model of what capacity actually exists in your shop. That model is a small hierarchy of objects — work center group, work center, machine center, shop calendar — and how carefully you set them up determines whether the dates the system computes mean anything. This page is the reference for that hierarchy: what each object is for, how a calendar turns into concrete open-time windows, how “capacity” and “load” are actually calculated, and a unit-of-measure trap that has quietly broken more than one shop’s schedule.
The hierarchy
Business Central arranges capacity in three levels, each one optional except the middle one:
- Work center group — the top level, purely organizational. A group of work centers, useful for reporting and filtering, but not itself a place work happens.
- Work center — the level every routing operation ultimately schedules against. A work center represents a department, a resource, or a group of interchangeable capacity — “Welding,” “Ovens,” “Assembly Line 2.” Every work center belongs to exactly one work center group (or none).
- Machine center — an optional finer-grained layer under a work center, representing one physical machine or one specific resource. A machine center belongs to exactly one work center. A routing operation can point at a work center directly, or at a specific machine center within it — the routing decides how granular the schedule needs to be.
The work center’s own capacity fields — how many units run in parallel, how efficient it runs, what calendar governs it — combine with whatever machine centers sit beneath it (if any) to determine the total available capacity that flows up. Whether a work center’s own capacity fields matter or get replaced entirely by the sum of its machine centers depends on one setting, covered below.
Capacity, efficiency, and the two dials that aren’t the same thing
Two fields on a work center (and, separately, on each machine center) do almost all of the work of describing reality:
- Capacity — how many units of this resource run at the same time. A single oven is capacity 1; a bank of three identical ovens working in parallel is capacity 3. If your Business Central license doesn’t include machine centers, this is the only lever you have for representing parallel resources — it’s the difference between modeling three ovens as “one resource that can do three things at once” versus needing three separate machine centers.
- Efficiency — the percentage of the expected standard output that this resource actually delivers. Efficiency 100 means real output matches the book-time standard exactly; a well-worn machine, an operator team still on the learning curve, or a process with a lot of built-in slack shows up as an efficiency below 100.
These two dials interact with the routing line’s time fields differently, and the difference is easy to get backwards. Run time duration scales with both — it’s calculated as run time divided by efficiency, divided by capacity (with capacity here meaning the smaller of the work center’s own capacity and whatever the specific routing line asks for). Setup time, by contrast, gets its allocated amount scaled by capacity — set up two parallel machines for the same job and the allocated setup time doubles, because you genuinely have to set up two machines — while its duration scales only by efficiency. The practical upshot: capacity and efficiency both compress or stretch a schedule, but they don’t do it identically to every time element, and modeling a resource’s parallelism as “efficiency 300%” instead of “capacity 3” (or vice versa) will schedule differently even though both sound like “three times the throughput” in conversation.
A small worked comparison makes the difference concrete. Take a routing operation with 2 hours of book run time. At efficiency 100% and capacity 1, it takes 2 hours of wall-clock time — the baseline case. Drop efficiency to 80% with capacity still 1, and the same 2 hours of book time now takes 2.5 hours in the real world, because the resource is doing the work more slowly than standard. Now instead model the same resource as capacity 2 at efficiency 100% — representing two identical units sharing the load — and the same 2 hours of book time completes in roughly 1 hour, because two units are absorbing the work in parallel. Same book time, three different wall-clock outcomes, purely from how capacity and efficiency were set — which is exactly why getting these two fields right matters as much as getting the routing’s raw time values right.
Shop calendars: from a weekly pattern to real time buckets
A shop calendar defines a shop’s standard working pattern: which days of the week are working days, what shift windows exist on each (a calendar can carry more than one shift per day), and which specific dates are holidays. Any day the calendar doesn’t define as a working day — a weekend nobody configured, an unlisted holiday — is treated as zero available capacity by default, which is itself worth knowing: a shop calendar you never finish setting up doesn’t fail loudly, it just quietly schedules through days that should have been closed, or blocks days that should have been open.
A shop calendar on its own is a template. It becomes usable capacity only when it’s assigned to a work center (via the Shop Calendar Code field) and then calculated — an explicit action that explodes the calendar’s weekly pattern, holidays, and the work center’s own capacity and efficiency values into calendar entries: one concrete record per resource per working period, each carrying an actual date, a start and end time, and an effective capacity figure. This calculated calendar is what every scheduling calculation — forward, backward, load report, the one narrow finite-loading feature Business Central has — actually reads. Change the work center’s capacity or efficiency, or change the underlying shop calendar, and the calendar has to be recalculated for the change to take effect; nothing recalculates automatically in the background. A calendar that was calculated a year ago and never touched since is silently running on last year’s holidays.
Consolidated calendars: when a work center is really just its machines
There’s a specific setup pattern worth knowing about: turning on a work center’s Consolidated Calendar toggle changes what “the work center’s capacity” even means. With it on, the work center stops having capacity of its own and instead becomes the sum of whatever machine centers sit beneath it — each machine center’s own efficiency effectively converts into the work center’s combined capacity figure. This is the right setup when a work center genuinely is nothing more than a collection of individually-tracked machines (three packing tables, each its own machine center) and you want the work center level to show the honest aggregate. It’s the wrong setup — and worth checking if a work center’s total capacity looks inexplicably low or zero — if the intent was for the work center itself to carry capacity independent of any machine centers underneath it.
Capacity vs. load: supply and demand, two different tables
This is the distinction the rest of the site leans on, so it’s worth being precise here. Capacity is supply — it lives on calendar entries, and it answers “how much time is actually available at this resource, in this window.” Load is demand — it comes from production order capacity need records, one or more per scheduled operation, and it answers “how much time has been asked of this resource, in this window, by everything currently scheduled onto it.” A work center’s load report is nothing more exotic than lining these two tables up side by side, period by period, and showing the difference. When load exceeds capacity in a given window, that resource is overloaded for that period — Business Central will show you that clearly. What it does with that fact by default, and the one setup that changes it, is the subject of Business Central Is Infinite-Loading.
The unit-of-measure trap
Every routing line’s time fields — setup, run, wait, move — each carry their own unit-of-measure code, independent of each other and independent of the work center. A work center, separately, has its own Unit of Measure Code, which governs the base unit its capacity and costing are expressed in. Business Central converts faithfully between whichever unit a routing line’s time is entered in and whichever unit the work center’s capacity is measured in — but that conversion is only correct if both codes say what you think they say.
The failure mode is specific and doesn’t announce itself: enter a run time meant to be minutes on a routing line whose time unit code is actually configured for hours, and the schedule doesn’t error — it computes a mathematically consistent result that reserves sixty times the intended duration. A two-minute operation books a two-hour block; a routing that should finish in a day spans two months. Nothing in the UI flags this, because from the system’s point of view nothing is wrong — you told it the time was in hours, and it scheduled hours. The tell is usually a production order whose dates look absurd relative to the work being described, or a work center whose load report shows near-permanent, implausible overload. When either shows up, checking the unit-of-measure code on the routing line’s time fields against what the work center actually expects is the first thing worth doing, before assuming the schedule itself is wrong.
Practical guidance: when machine centers earn their keep
Machine centers aren’t required, and adding them where they’re not needed is pure setup overhead for no scheduling benefit. They’re worth the effort when the machines inside a work center genuinely differ from each other in ways that matter to the schedule: different speeds, different calendars (one machine down for maintenance while its siblings run), or when you specifically want operations, load, and drag-drop rescheduling to reference one physical asset rather than an interchangeable pool. If every “oven” in a work center really is interchangeable — same speed, same calendar, same everything — modeling them as one work center with Capacity = 3 is simpler, accurate, and exactly what the capacity field exists for. Reach for machine centers when interchangeability stops being true.
For how these objects feed the actual date-computation walk, see How Business Central Schedules a Production Order, Step by Step. For the concept-level version of shift calendars and real capacity — including why a “40-hour week” is closer to fiction than fact — see Modeling Real Capacity: Shifts, Calendars, Efficiency, and Parallel Machines. To set up a shop calendar step by step, see Model Shifts and Shop Calendars in Business Central.
For Microsoft’s own field-by-field reference: Set up work centers and machine centers, Set up shop calendars, and View load on work and machine centers.