Finite Scheduling: Generate, Review, Accept
This is the core of SmartFlow APS: an automated solve that checks every operation against every other operation sharing a work center, so no machine is ever double-booked in the resulting plan — the one property standard Microsoft Dynamics 365 Business Central’s own date math doesn’t check for (see Business Central Is Infinite-Loading). Nothing it proposes writes to your production orders until you review it and click Accept.
When to reach for it
- A work center’s capacity heatmap shows red — orders are stacked on it — and you want the system to resolve the overload, not just flag it.
- You need a realistic start and finish for every operation that actually respects your shifts, machine counts, and routing precedence, without working it out by hand.
- You want an automated starting point you can still fine-tune by dragging on the same board afterward.
Before you run it
Each work center you plan to include should have a shop calendar with shifts and a capacity (machine count) set — the solver only ever schedules inside the open windows those calendars define. Routing operations should carry run time and, where relevant, setup time and a predecessor link, so the solver knows what has to finish before what starts.
The steps
- Open the Scheduler and set the Scope selector to the order statuses you want the plan to cover: Released Only, Firm Planned + Released (the default), or Planned to Released — the last of these pulls in Planned-status orders as pinned context so the routing chain stays correct, without moving them. Only Firm Planned and Released operations are ever written back on Accept, regardless of scope.
- Optionally open the solve-time control to change how long the solver may run on this pass (30–480 seconds, default 60) — more time can tighten the plan closer to provably optimal; the solver stops on its own the moment it proves one, so this is a ceiling, not a guaranteed wait.
- Choose Run Finite Scheduler from the Process actions. The solver runs and returns in a few seconds to a couple of minutes depending on scope and the time limit.
- The review panel opens with a Before → After comparison. Nothing has changed yet.
- Review it (see below), then Accept to write the plan to your production-order routing lines, or Reject to discard it and leave every date exactly as it was.
Reading the review panel
The panel shows the current schedule (“Before”) stacked above the proposed one (“After”) on the same Gantt grammar you already know from the live board, with a dotted line connecting every operation the solver actually moved to its new slot. The After strip stays interactive — you can drag a bar on it to override the solver’s placement before you Accept, and Accept commits the solver’s plan together with your manual edit.
Auto-shift badges. Every operation the solver moved carries a small badge showing how far and, on hover, why: Capacity (the resource was already busy), Calendar (the original time fell outside an open shift), Predecessor (it was waiting on the operation before it in the routing), or Frozen (it was held in place by the frozen horizon rather than moved). A toggle lets you emphasize just the changed operations and dim everything else, so a large plan doesn’t bury the handful of orders that actually shifted.
KPI cards, before → after. Makespan, late orders, on-time percentage, total tardiness, and setup time, each shown as its old value and its new one, so you can see at a glance what the plan actually bought you — not just that something changed.
“Why the plan changed.” A collapsible panel narrates the run in plain language — how many operations moved and the dominant reasons — generated from the actual solve, not a canned description.
Honesty chips — reading what the review panel is actually telling you
The review panel is built to say what it doesn’t know, not just what it does. A few chips worth understanding:
- An optimality-gap chip tells you how close the returned plan is to a proven-best one. If the solver hit its time limit before it could prove optimality, the chip says so explicitly and suggests raising the solve-time limit for a tighter plan next time — rather than presenting a time-limited result as though it were guaranteed best.
- A precedence-violations chip, if it ever appears, is the panel’s own self-check refusing to endorse a broken plan — its wording is direct: don’t Accept. You should never see this in normal operation; if you do, treat it as a bug report and contact support before accepting anything.
- A frozen-zone pin count confirms how many operations the solver held in place because they fell inside your frozen horizon.
- A small family of version-skew chips cover capability areas (like frozen-horizon enforcement or alternate-machine assignment) that depend on which build of the scheduling service answered your request — a chip reads “not enforced by this scheduling service version” rather than silently assuming a capability that a particular deployment might not actually have. This is why the panel can tell you honestly what it verified about a given run, instead of only what it hoped for.
After you Accept
A results panel confirms what actually happened — in green if everything applied cleanly, amber if some operations were skipped with a reason (an order landed in the frozen horizon, or Business Central itself rejected a specific line), or red if nothing applied at all, with the reason spelled out rather than a generic failure message.
How this relates to the Sequence Optimizer
Finite scheduling and sequence optimization are two different tools solving two different halves of the same problem today, and they don’t talk to each other yet. The finite scheduler respects capacity, calendars, and due dates but does not minimize changeover time in the same pass. If your shop cares about changeover, run Sequence Optimization as a separate pass — before or after a finite run, whichever your workflow prefers. Sequence-Dependent Setup explains why a joint solve of both objectives together, once available, will be able to find sequences that neither tool alone can today.
Concepts behind this feature
Finite vs Infinite Capacity Scheduling, Explained Properly walks through the mechanism this page automates. Modeling Real Capacity explains what the solver actually needs from your shift calendars and work-center setup to do this correctly.
This page explains changeover elimination inside the finite solve as a scheduling concept. Changeover elimination inside the finite solve is on the SmartFlow APS roadmap and is not enabled in the current production release. For what SmartFlow APS does today, see the User Guide.