How Business Central Schedules a Production Order
Every production order in Microsoft Dynamics 365 Business Central gets its dates from two pieces of master data: a routing, which lists the operations and how long each one takes, and a bill of materials (BOM), which lists what gets consumed. The routing is what actually schedules the order — it’s the sequence of steps the system walks, in order, to work out when the order starts, when each operation runs, and when the whole thing finishes.
This page walks that mechanism end to end: what a routing operation is made of, how Business Central decides whether to schedule forward or backward, how it consults the calendar while it does it, and what actually happens when you refresh or replan an order. If you’ve ever wondered why a production order’s start date landed where it did, or why refreshing an order moved dates you didn’t touch, this is the mechanism underneath.
The routing is the schedule
A routing is an ordered list of operations, each pointing at a work center or machine center. When a production order is created from an item that has a routing, Business Central copies that routing onto the order as production order routing lines — one line per operation, carrying its own dates, times, and status. The routing header can be serial (operations run one after another by operation number) or parallel (branches converge on a later operation, controlled by a “next operation” reference rather than strict numbering) — most shops use serial routings, but parallel routings exist for processes where independent sub-steps genuinely run at the same time before merging into a final operation.
Each operation carries four time elements, and getting them right matters more than it looks:
- Setup time — the one-time preparation before work starts: a tool change, a fixture swap, a machine calibration. It’s fixed per operation and doesn’t scale with how many units you’re running.
- Run time — the per-unit processing time, multiplied by the operation’s quantity. This is the element that scales with lot size.
- Wait time — time that has to pass after the run finishes before the part can move on — drying, cooling, curing. It extends how long the operation takes elapsed, but it doesn’t tie up the work center itself.
- Move time — the transit time to physically get the part to the next work center. Like wait time, it adds to the elapsed schedule without consuming the work center’s own capacity.
On top of those four, the work center itself carries a queue time — a buffer between when material arrives at a resource and when work on it can actually start. Queue, setup, run, wait, and move all add together to produce the operation’s total span, and the sum across every operation in the routing (plus each work center’s queue time) is what becomes the item’s production lead time. It’s worth being precise about this distinction: setup and run time are what the work center is actually busy doing — they’re what shows up as load against that resource’s capacity. Wait, move, and queue time pass, and they lengthen the calendar, but they don’t occupy the machine.
One detail that trips up a lot of routings: every one of the four time fields has its own unit-of-measure code. Setup time can be entered in minutes while run time is entered in hours on the same operation line, and Business Central will faithfully convert and schedule both correctly — but only if the unit codes are actually set the way you meant them. A run time of “2” that’s supposed to mean two minutes but is coded as hours schedules an operation sixty times longer than intended, and because the math is internally consistent, nothing errors — the order just quietly reserves a day of machine time for a two-minute job. If a production order’s dates look wildly wrong, checking the unit-of-measure code on each time field is one of the first places to look, right alongside the routing’s raw numbers.
Forward or backward: which direction BC schedules in
Business Central schedules a production order in one of two directions, and which one it uses depends on what you gave it to schedule from:
- Backward scheduling starts from a due date and works backward through the routing, subtracting each operation’s time (plus queue, wait, and move) to arrive at a starting date. This is the default whenever a due date drives the order — for example, an order created to meet a sales order’s requested ship date.
- Forward scheduling starts from a starting date and works forward through the routing, adding time to arrive at a finishing date. This is what you get when you tell the system when to start rather than when to finish.
Backward scheduling has an honest failure mode worth knowing about: if the routing needs more time than exists between today and the due date, the computed starting date lands in the past. Business Central doesn’t refuse to create that schedule or flag it as broken — it just states the arithmetic truth, which is that meeting this due date would have required starting before now. A production order with a starting date behind today’s date isn’t a data-entry mistake; it’s the system reporting, correctly, that the math doesn’t work. What it means practically is that the due date is already at risk, and it’s on the planner to notice and react — compress the routing, push the due date, add a shift, or accept the order will run late.
A worked example, start to finish
Take a three-operation routing — cut, weld, paint — for an order due Friday at end of shift, backward-scheduled. Business Central starts at Friday’s closing time and walks backward: paint needs four hours, so it works backward from Friday close to find four hours of open paint-booth calendar, landing it Friday morning through early afternoon. Weld, the operation before paint, then has to finish by the moment paint starts — so the scheduler continues walking backward from there, through weld’s open calendar windows, however many hours weld needs. Cut, first in the routing, gets the same treatment relative to when weld needs to start. If any of the three resources is closed for a chunk of that window — a half-day for a holiday, an overnight gap — the walk simply continues into the next open calendar entry further back, which is exactly the mechanism described above applied three times in a row, chained by precedence.
The order’s own starting date, the one shown on the header, is whatever the walk lands on once it works all the way back through cut. If that computed starting date is before today, that’s the “backward scheduling lands in the past” failure mode described above, made concrete: the routing, walked honestly against the calendar, needed more time than exists between now and Friday.
How the calendar gets walked
Whichever direction it’s scheduling, Business Central lays each time element into the resource’s actual open hours — it doesn’t allocate time across nights, weekends, or closed periods. That’s possible because a work center (or machine center) carries a shop calendar, which explodes into calendar entries: concrete blocks of available time per resource per day, built from the calendar’s defined shifts, holidays, the resource’s capacity (how many units run in parallel), and its efficiency percentage (how book time scales to real-world time). When the scheduler is walking an operation’s run time backward or forward, it’s moving through these calendar entries one at a time, only ever placing time inside a window the calendar says is open. If a routing operation needs three hours and the work center closes in ninety minutes, the scheduler doesn’t sit there overwriting closed time — it consumes the ninety minutes available, then continues into the next open calendar entry, which might be tomorrow morning.
This is the piece that’s genuinely easy to misread as “Business Central does capacity-aware scheduling.” It does — for the single order it’s currently scheduling, against that resource’s open hours. What it is not doing, by default, is checking whether another production order already claimed that same slot. Every order gets scheduled as if it’s the only thing happening in the plant, and that mechanism — and the one narrow feature that changes it — is its own page: Business Central Is Infinite-Loading.
Refresh and Replan: what actually recalculates
Master data changes after an order exists — someone edits a routing, adjusts a BOM, changes a due date — and Business Central doesn’t automatically ripple that into orders that already have their own copied routing lines. You have to explicitly ask it to recompute, and there are two distinct actions for that, with a real difference in scope:
- Replan (available on planned and firm planned orders) can be run at “All Levels” or “One Level.” All Levels walks down through the BOM and re-explodes subassemblies into their own child production orders where needed, recalculating the whole multilevel structure. One Level touches only the order in front of you.
- Refresh (available at any status) recalculates the order’s routing and components from the current item master data — current routing, current BOM, current lead times — without changing the order’s status. It’s the everyday tool for “the routing changed, make this order reflect it.”
Either way, what actually happens under the hood is the same scheduling walk described above, run again from scratch against the current calendar and current master data. This is also why refreshing an order can shift dates you didn’t touch: if the calendar changed, or a routing time changed, or an upstream operation’s duration changed, the whole downward cascade of starting/ending times for every subsequent operation recomputes to match — and if you’re keeping firm decisions in place manually on the shop floor, an unplanned refresh can quietly undo them. This is part of why in-process orders and orders someone is actively managing on a board need their own protection against getting silently rescheduled — a theme every scheduling tool sitting on top of Business Central has to solve for.
Where the computed dates actually live
Every operation’s computed Starting Date/Time and Ending Date/Time live on the production order routing line itself — one line per operation, so a five-operation routing has five independently dated lines, chained together by the sequencing logic above. The order header’s own starting and ending dates are derived from the first and last operation in that chain. Alongside the dates, Business Central also writes production order capacity need records — one or more per operation — which is where the demand side of the load calculation actually lives; a work center’s calendar entry holds the supply (how much capacity exists in a given window), and the capacity need records hold what’s been asked of it. Comparing those two is literally what a work center’s load report is doing.
None of this changes because you added machines, added shifts, or reorganized work centers into groups — the routing-driven walk described here is the same mechanism whether you’re modeling one work center or fifty. What does change the picture is how you set those resources up in the first place, which is the subject of the next page: Work Centers, Machine Centers, and Shop Calendars: Business Central’s Capacity Model.
For the concept-level version of forward vs. backward scheduling — including the failure modes of each approach and how finite scheduling reframes both — see Forward vs Backward Scheduling: When Each One Lies to You. For the deeper distinction between “the calendar is respected” and “capacity is respected,” see Finite vs Infinite Capacity Scheduling, Explained Properly.
For the authoritative, continuously-updated reference on routings and production orders, see Microsoft’s own documentation: Create routings, Set up work centers and machine centers, and About production orders.